From noreply@sourceforge.net Thu May 1 00:44:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 16:44:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-730229 ] stringprep not documented Message-ID: Bugs item #730229, was opened at 2003-04-30 10:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730229&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Martin v. Löwis (loewis) Summary: stringprep not documented Initial Comment: The stringprep module is not documented in the Library Reference. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-30 18:44 Message: Logged In: YES user_id=80475 Hmm, I see it in Python 2.3b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730229&group_id=5470 From noreply@sourceforge.net Thu May 1 00:56:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 16:56:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-730506 ] wdg["textvariable"] and setvar/getvar not compatible Message-ID: Bugs item #730506, was opened at 2003-04-30 16: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=730506&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: wdg["textvariable"] and setvar/getvar not compatible Initial Comment: In Python 2.2.2 and earlier, one could do: root = Tk() v = StringVar() l = Label(root, textvariable=v) l["textvariable"] and get back the name of the variable. This could then be used in l.setvar() and l.getvar() to set or get that variable. Such code is broken in Python 2.3b1 because l["textvariable"] returns a tcl object, and setvar/getvar don't recognize it. It's worth fixing because setvar and getvar seem to be the only way to deal with the thing returned by l["textvariable"]. A fix to consider is to enhance setvar and getvar so that they can deal with tcl objects (as well as with names of variables). This would still break any code that demanded a string back, but the usual reason to obtain the variable was to set or get it with setvar or getvar. So I think it would handle most problems. A less interesting fix is to have l["textvariable"] return a string. (Of course users can also disable returning objects.) A broader fix is to have l["textvariable"] return the original Tkinter Variable. That'd be truly wonderful. It would eliminate the need for setvar or getvar in all but the strangest cases (and the existing implementation would do fine in all others). It would certainly break some existing code (users would would have to disable returning objects to be fix that), but what better time to introduce it then when Tkinter is actually returning non-strings sometimes? I know I'm dreaming. I looked at Tkinter.py and it doesn't look like much fun to add (though it could be done by keeping a reference in the Tk object). -- Russell ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 From noreply@sourceforge.net Thu May 1 01:49:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 17:49:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-730229 ] stringprep not documented Message-ID: Bugs item #730229, was opened at 2003-04-30 11:10 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730229&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Martin v. Löwis (loewis) Summary: stringprep not documented Initial Comment: The stringprep module is not documented in the Library Reference. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-04-30 20:49 Message: Logged In: YES user_id=3066 That'll teach me to rely on my memory! Sorry; you're right. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-30 19:44 Message: Logged In: YES user_id=80475 Hmm, I see it in Python 2.3b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730229&group_id=5470 From noreply@sourceforge.net Thu May 1 06:26:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 22:26:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-729300 ] Compiling --with-pydebug=yes --with-threads=no fails Message-ID: Bugs item #729300, was opened at 2003-04-29 04:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729300&group_id=5470 Category: Threads Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: logistix (logistix) Assigned to: Martin v. Löwis (loewis) Summary: Compiling --with-pydebug=yes --with-threads=no fails Initial Comment: A PyGILstate_ function is called outside of a WITH_THREADS #ifdef. Of course all the PyGIL functions only exist when threads are enabled. The attached patch fixes it, although I don't know enough about the new GIL Implementation to verify that it's 'correct'. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-01 07:26 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pystate.c 2.27. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-04-29 13:49 Message: Logged In: YES user_id=14198 Thanks Martin - please check this in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-29 13:42 Message: Logged In: YES user_id=21627 Mark, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729300&group_id=5470 From noreply@sourceforge.net Thu May 1 06:50:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Apr 2003 22:50:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-730506 ] wdg["textvariable"] and setvar/getvar not compatible Message-ID: Bugs item #730506, was opened at 2003-05-01 01:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: wdg["textvariable"] and setvar/getvar not compatible Initial Comment: In Python 2.2.2 and earlier, one could do: root = Tk() v = StringVar() l = Label(root, textvariable=v) l["textvariable"] and get back the name of the variable. This could then be used in l.setvar() and l.getvar() to set or get that variable. Such code is broken in Python 2.3b1 because l["textvariable"] returns a tcl object, and setvar/getvar don't recognize it. It's worth fixing because setvar and getvar seem to be the only way to deal with the thing returned by l["textvariable"]. A fix to consider is to enhance setvar and getvar so that they can deal with tcl objects (as well as with names of variables). This would still break any code that demanded a string back, but the usual reason to obtain the variable was to set or get it with setvar or getvar. So I think it would handle most problems. A less interesting fix is to have l["textvariable"] return a string. (Of course users can also disable returning objects.) A broader fix is to have l["textvariable"] return the original Tkinter Variable. That'd be truly wonderful. It would eliminate the need for setvar or getvar in all but the strangest cases (and the existing implementation would do fine in all others). It would certainly break some existing code (users would would have to disable returning objects to be fix that), but what better time to introduce it then when Tkinter is actually returning non-strings sometimes? I know I'm dreaming. I looked at Tkinter.py and it doesn't look like much fun to add (though it could be done by keeping a reference in the Tk object). -- Russell ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-01 07:50 Message: Logged In: YES user_id=21627 This is fixed in _tkinter.c 1.156, by having getvar/setvar accept tcl objects. Your desired behaviour of having ["textvariable"] return a Variable object would break your own code, as setvar would again complain about a type error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 From noreply@sourceforge.net Thu May 1 11:15:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 03:15:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-730685 ] itertools.islice stop argument is not optional Message-ID: Bugs item #730685, was opened at 2003-05-01 11:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730685&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.islice stop argument is not optional Initial Comment: The "stop" argument in the itertools islice function is not optional. This prevents useful options such as islice(it,10, None) # Everything from the 10th onward islice(it, 0, None, 2) # Every other item I am using None here to mean that the stop argument is omitted - -1 might work as well. Keyword arguments may be better, but may be overkill. For normal sequences, len(seq) can be used to give a stop value meaning "everything". This isn't possible in general for iterators. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730685&group_id=5470 From noreply@sourceforge.net Thu May 1 11:16:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 03:16:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-730685 ] itertools.islice stop argument is not optional Message-ID: Bugs item #730685, was opened at 2003-05-01 11:15 Message generated for change (Settings changed) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730685&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) >Assigned to: Raymond Hettinger (rhettinger) Summary: itertools.islice stop argument is not optional Initial Comment: The "stop" argument in the itertools islice function is not optional. This prevents useful options such as islice(it,10, None) # Everything from the 10th onward islice(it, 0, None, 2) # Every other item I am using None here to mean that the stop argument is omitted - -1 might work as well. Keyword arguments may be better, but may be overkill. For normal sequences, len(seq) can be used to give a stop value meaning "everything". This isn't possible in general for iterators. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730685&group_id=5470 From noreply@sourceforge.net Thu May 1 13:11:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 05:11:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 18:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 14:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Thu May 1 14:58:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 06:58:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 09:45 Message generated for change (Comment added) made by loechelt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- >Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-01 06:58 Message: Logged In: YES user_id=142817 Thanks for pointing this prior bug report to me. I found the discussions very insightful. Regarding the changes made to __iter__, I have no problems from an application point of view. I just need to know the designed behavior and adjust my code accordingly. From a philosophical point of view, I have mixed feelings about making __iter__ depend upon an overridden __getitem__. I can see the advantages of simplicity in writing extension classes, but you also lose access to the base __iter__ functionality, although I cannot think of an example of where that would be important off the top of my head. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 05:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Thu May 1 18:20:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 10:20:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 11:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 12:20 Message: Logged In: YES user_id=80475 This was an intentional change. The idea was to make sure that calls to iter() would respect an overriden __getitem__() method. We're taking another look at the decision and thinking about whether it made sense with respect to least surprise, utility, consistency, and performance. ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-01 08:58 Message: Logged In: YES user_id=142817 Thanks for pointing this prior bug report to me. I found the discussions very insightful. Regarding the changes made to __iter__, I have no problems from an application point of view. I just need to know the designed behavior and adjust my code accordingly. From a philosophical point of view, I have mixed feelings about making __iter__ depend upon an overridden __getitem__. I can see the advantages of simplicity in writing extension classes, but you also lose access to the base __iter__ functionality, although I cannot think of an example of where that would be important off the top of my head. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 07:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Thu May 1 19:42:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 11:42:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-730938 ] Python 2.3 bsddb docs need update Message-ID: Bugs item #730938, was opened at 2003-05-01 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730938&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Gregory P. Smith (greg) Summary: Python 2.3 bsddb docs need update Initial Comment: We need to do /something/ about the bsddb module documentation in Python 2.3. The current docs are for the old bsddb module and they're worse than out-of-date. Ideally, we'd import pybsddb's documentation in Python latex format, and add docs for all the auxiliary modules that come in the bsddb package. If we don't have time for that, we should at least update the docs to point to the pybsddb site and document the list of additional modules. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730938&group_id=5470 From noreply@sourceforge.net Thu May 1 20:12:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 12:12:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-730938 ] Python 2.3 bsddb docs need update Message-ID: Bugs item #730938, was opened at 2003-05-01 11:42 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730938&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Gregory P. Smith (greg) Summary: Python 2.3 bsddb docs need update Initial Comment: We need to do /something/ about the bsddb module documentation in Python 2.3. The current docs are for the old bsddb module and they're worse than out-of-date. Ideally, we'd import pybsddb's documentation in Python latex format, and add docs for all the auxiliary modules that come in the bsddb package. If we don't have time for that, we should at least update the docs to point to the pybsddb site and document the list of additional modules. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-05-01 12:12 Message: Logged In: YES user_id=413 Yes, this is important. I've attached a patch against the current python documentation that points to pybsddb. I've never edited the python latex docs before and am not currently setup for compiling/viewing the updates or verifying that i used the correct syntax. can you review it and check it in if it makes sense? unfortunately even the pybsddb project's documentation is a bit dated (mostly in that several new features/functions have been exposed since it was written) but it is a *much* better starting point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730938&group_id=5470 From noreply@sourceforge.net Thu May 1 20:15:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 12:15:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-730938 ] Python 2.3 bsddb docs need update Message-ID: Bugs item #730938, was opened at 2003-05-01 14:42 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730938&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Python 2.3 bsddb docs need update Initial Comment: We need to do /something/ about the bsddb module documentation in Python 2.3. The current docs are for the old bsddb module and they're worse than out-of-date. Ideally, we'd import pybsddb's documentation in Python latex format, and add docs for all the auxiliary modules that come in the bsddb package. If we don't have time for that, we should at least update the docs to point to the pybsddb site and document the list of additional modules. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-01 15:15 Message: Logged In: YES user_id=12800 Taking ownership to review ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-05-01 15:12 Message: Logged In: YES user_id=413 Yes, this is important. I've attached a patch against the current python documentation that points to pybsddb. I've never edited the python latex docs before and am not currently setup for compiling/viewing the updates or verifying that i used the correct syntax. can you review it and check it in if it makes sense? unfortunately even the pybsddb project's documentation is a bit dated (mostly in that several new features/functions have been exposed since it was written) but it is a *much* better starting point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730938&group_id=5470 From noreply@sourceforge.net Thu May 1 20:48:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 12:48:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-730963 ] HTTPRedirectHandler variable out of scope Message-ID: Bugs item #730963, was opened at 2003-05-01 15: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=730963&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPRedirectHandler variable out of scope Initial Comment: Within class HTTPRedirectHandler(BaseHandler), variable newurl is local to http_error_302, but is used in redirect_request. Since method redirect_request isn't called anywhere else, newurl can just be added to the signature. def redirect_request(self, req, fp, code, msg, headers, newurl): and new = self.redirect_request(req, fp, code, msg, headers, newurl) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730963&group_id=5470 From noreply@sourceforge.net Fri May 2 03:44:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 19:44:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-731115 ] pimp.py has old URL for default database Message-ID: Bugs item #731115, was opened at 2003-05-01 19: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=731115&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jack Jansen (jackjansen) Summary: pimp.py has old URL for default database Initial Comment: On line 46 in pimp.py, the URL for the default pimp database specifies www.cwi.nl. It should be updated to homepages.cwi.nl, to which it now gets redirected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731115&group_id=5470 From noreply@sourceforge.net Fri May 2 03:48:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 01 May 2003 19:48:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-731116 ] urllib2 raises AttributeError on redirect Message-ID: Bugs item #731116, was opened at 2003-05-01 19: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=731116&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 raises AttributeError on redirect Initial Comment: The code import urllib2 f = urllib2.urlopen('http://www.cwi.nl/~jack/pimp/pimp-darwin-6.5- Power_Macintosh.plist') which is executed by pimp.py when the Macintosh PackageManager is initially brought up, raises an AttributeError when it gets redirected to homepages.cwi.nl. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 From noreply@sourceforge.net Fri May 2 13:02:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 05:02:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-731116 ] urllib2 raises AttributeError on redirect Message-ID: Bugs item #731116, was opened at 2003-05-02 04:48 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) >Assigned to: Raymond Hettinger (rhettinger) Summary: urllib2 raises AttributeError on redirect Initial Comment: The code import urllib2 f = urllib2.urlopen('http://www.cwi.nl/~jack/pimp/pimp-darwin-6.5- Power_Macintosh.plist') which is executed by pimp.py when the Macintosh PackageManager is initially brought up, raises an AttributeError when it gets redirected to homepages.cwi.nl. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 14:02 Message: Logged In: YES user_id=45365 The problem is a last-minute checkin before 2.3b1, rev 1.39. It refers to a method() method on requests which doesn't exist. Assigning to Raymond, as he did the checkin so he's the easiest scapegoat:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 From noreply@sourceforge.net Fri May 2 16:20:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 08:20:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-731403 ] test_tarfile writes in Lib/test directory Message-ID: Bugs item #731403, was opened at 2003-05-02 17:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731403&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: test_tarfile writes in Lib/test directory Initial Comment: Test_tarfile writes a file in the Lib/test directory, which fails if Python has been installed read-only. It would be better if it used test_support.TESTFN as the basis for a filename to write to. Here's the message for a binary install on MacOSX (framework Python): test test_tarfile crashed -- exceptions.IOError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/test/testtar.tar.gz' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731403&group_id=5470 From noreply@sourceforge.net Fri May 2 18:56:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 10:56:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable Message-ID: Bugs item #731501, was opened at 2003-05-02 13: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=731501&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Vargish (vargish) Assigned to: Nobody/Anonymous (nobody) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 From noreply@sourceforge.net Fri May 2 18:58:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 10:58:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable Message-ID: Bugs item #731501, was opened at 2003-05-02 13:56 Message generated for change (Settings changed) made by vargish You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Vargish (vargish) >Assigned to: Skip Montanaro (montanaro) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 From noreply@sourceforge.net Fri May 2 19:29:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 11:29:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads Message-ID: Bugs item #539990, was opened at 2002-04-05 23:29 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: Wont Fix Priority: 7 Submitted By: Pieter Claerhout (pclaerhout) Assigned to: Just van Rossum (jvr) Summary: Framework.mainloop() - multiple threads Initial Comment: I tried to use the threading module to start the XML RPC server in a different thread (xmlrpcServer itself also is a threaded piece of code), but that seems to conflict with the mainloop. If you start this application, it starts the thread, starts the mainloop and stays in there, once you finish the mainloop, the thread continues. You've stumbled on a bug in Framework.mainloop(): it doesn't know anything about multiple threads. It gives time to other applications (by calling WaitNextEvent) but not to other threads within Python. Also see http://mail.python.org/pipermail/pythonmac-sig/2002- April/005416.html and http://mail.python.org/pipermail/pythonmac-sig/2002- April/005428.html ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-02 20:28 Message: Logged In: YES user_id=92689 I finally got around playing with autoGIL in the IDE (briefly, though): it seems to work just fine! Reopeing this report. Jack, I could add autoGIL.c to the Mac tree if you want. A good experiment would be to make the PackagaManager threaded... ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2003-04-25 11:35 Message: Logged In: YES user_id=446428 Probably fixing this will also allow to run a long computation and still use the IDE for writing other code, or run commands in interactive mode. Sounds like a cool feature! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 11:43 Message: Logged In: YES user_id=45365 If that is true I would be very happy. Could you please investigate this and put it in if it works? Before 2.3b1 please: I don't want to mess with the core of the MacOS support modules after that... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-24 19:51 Message: Logged In: YES user_id=92689 Jack, have you forgotten about autoGIL? It's quite likely that the autoGIL module (as part of the PyObjC project) would fix this issue out of the box on OSX. Do "import autoGIL; autoGIL.installAutoGIL()" before you enter the event loop and the second thread gets time to run. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-24 17:45 Message: Logged In: YES user_id=45365 Let's admit this isn't going to be fixed unless someone wants it real bad. Pieter: if you want it real bad then reopen the bug and I'll find time for it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-22 16:03 Message: Logged In: YES user_id=45365 After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed. A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-07 23:26 Message: Logged In: YES user_id=45365 Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 From noreply@sourceforge.net Fri May 2 20:07:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 12:07:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-730685 ] itertools.islice stop argument is not optional Message-ID: Bugs item #730685, was opened at 2003-05-01 05:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730685&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools.islice stop argument is not optional Initial Comment: The "stop" argument in the itertools islice function is not optional. This prevents useful options such as islice(it,10, None) # Everything from the 10th onward islice(it, 0, None, 2) # Every other item I am using None here to mean that the stop argument is omitted - -1 might work as well. Keyword arguments may be better, but may be overkill. For normal sequences, len(seq) can be used to give a stop value meaning "everything". This isn't possible in general for iterators. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-02 14:07 Message: Logged In: YES user_id=80475 Thanks for the report. Fixed to match documentation. Make the code sample also match. Improves usability for islice(). See: Modules/itertoolsmodule.c 1.11 Doc/lib/libitertools.tex 1.8 Lib/test/test_itertools.py 1.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730685&group_id=5470 From noreply@sourceforge.net Fri May 2 20:10:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 12:10:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-731116 ] urllib2 raises AttributeError on redirect Message-ID: Bugs item #731116, was opened at 2003-05-01 21:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Raymond Hettinger (rhettinger) Summary: urllib2 raises AttributeError on redirect Initial Comment: The code import urllib2 f = urllib2.urlopen('http://www.cwi.nl/~jack/pimp/pimp-darwin-6.5- Power_Macintosh.plist') which is executed by pimp.py when the Macintosh PackageManager is initially brought up, raises an AttributeError when it gets redirected to homepages.cwi.nl. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-02 14:09 Message: Logged In: YES user_id=80475 Please post the whole traceback. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 07:02 Message: Logged In: YES user_id=45365 The problem is a last-minute checkin before 2.3b1, rev 1.39. It refers to a method() method on requests which doesn't exist. Assigning to Raymond, as he did the checkin so he's the easiest scapegoat:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 From noreply@sourceforge.net Fri May 2 21:17:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 13:17:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-731116 ] urllib2 raises AttributeError on redirect Message-ID: Bugs item #731116, was opened at 2003-05-01 19:48 Message generated for change (Comment added) made by davidmlewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Raymond Hettinger (rhettinger) Summary: urllib2 raises AttributeError on redirect Initial Comment: The code import urllib2 f = urllib2.urlopen('http://www.cwi.nl/~jack/pimp/pimp-darwin-6.5- Power_Macintosh.plist') which is executed by pimp.py when the Macintosh PackageManager is initially brought up, raises an AttributeError when it gets redirected to homepages.cwi.nl. ---------------------------------------------------------------------- >Comment By: David Lewis (davidmlewis) Date: 2003-05-02 13:17 Message: Logged In: YES user_id=626943 I filed a patch under number 731153, if you want to review it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-02 12:09 Message: Logged In: YES user_id=80475 Please post the whole traceback. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 05:02 Message: Logged In: YES user_id=45365 The problem is a last-minute checkin before 2.3b1, rev 1.39. It refers to a method() method on requests which doesn't exist. Assigning to Raymond, as he did the checkin so he's the easiest scapegoat:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 From noreply@sourceforge.net Fri May 2 21:18:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 13:18:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-731115 ] pimp.py has old URL for default database Message-ID: Bugs item #731115, was opened at 2003-05-01 19:44 Message generated for change (Comment added) made by davidmlewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731115&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jack Jansen (jackjansen) Summary: pimp.py has old URL for default database Initial Comment: On line 46 in pimp.py, the URL for the default pimp database specifies www.cwi.nl. It should be updated to homepages.cwi.nl, to which it now gets redirected. ---------------------------------------------------------------------- >Comment By: David Lewis (davidmlewis) Date: 2003-05-02 13:18 Message: Logged In: YES user_id=626943 I filed a patch last night under 731151. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731115&group_id=5470 From noreply@sourceforge.net Fri May 2 21:22:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 13:22:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads Message-ID: Bugs item #539990, was opened at 2002-04-05 23:29 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: Wont Fix Priority: 7 Submitted By: Pieter Claerhout (pclaerhout) Assigned to: Just van Rossum (jvr) Summary: Framework.mainloop() - multiple threads Initial Comment: I tried to use the threading module to start the XML RPC server in a different thread (xmlrpcServer itself also is a threaded piece of code), but that seems to conflict with the mainloop. If you start this application, it starts the thread, starts the mainloop and stays in there, once you finish the mainloop, the thread continues. You've stumbled on a bug in Framework.mainloop(): it doesn't know anything about multiple threads. It gives time to other applications (by calling WaitNextEvent) but not to other threads within Python. Also see http://mail.python.org/pipermail/pythonmac-sig/2002- April/005416.html and http://mail.python.org/pipermail/pythonmac-sig/2002- April/005428.html ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 22:22 Message: Logged In: YES user_id=45365 What do you mean by "add it to the mac tree"? Anyway: I would love to have this functionality, but I think it is probably prudent to do development on a branch (unless you're pretty sure of it). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-02 20:28 Message: Logged In: YES user_id=92689 I finally got around playing with autoGIL in the IDE (briefly, though): it seems to work just fine! Reopeing this report. Jack, I could add autoGIL.c to the Mac tree if you want. A good experiment would be to make the PackagaManager threaded... ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2003-04-25 11:35 Message: Logged In: YES user_id=446428 Probably fixing this will also allow to run a long computation and still use the IDE for writing other code, or run commands in interactive mode. Sounds like a cool feature! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 11:43 Message: Logged In: YES user_id=45365 If that is true I would be very happy. Could you please investigate this and put it in if it works? Before 2.3b1 please: I don't want to mess with the core of the MacOS support modules after that... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-24 19:51 Message: Logged In: YES user_id=92689 Jack, have you forgotten about autoGIL? It's quite likely that the autoGIL module (as part of the PyObjC project) would fix this issue out of the box on OSX. Do "import autoGIL; autoGIL.installAutoGIL()" before you enter the event loop and the second thread gets time to run. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-24 17:45 Message: Logged In: YES user_id=45365 Let's admit this isn't going to be fixed unless someone wants it real bad. Pieter: if you want it real bad then reopen the bug and I'll find time for it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-22 16:03 Message: Logged In: YES user_id=45365 After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed. A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-07 23:26 Message: Logged In: YES user_id=45365 Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 From noreply@sourceforge.net Fri May 2 21:26:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 13:26:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-731115 ] pimp.py has old URL for default database Message-ID: Bugs item #731115, was opened at 2003-05-02 04:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731115&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jack Jansen (jackjansen) Summary: pimp.py has old URL for default database Initial Comment: On line 46 in pimp.py, the URL for the default pimp database specifies www.cwi.nl. It should be updated to homepages.cwi.nl, to which it now gets redirected. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 22:26 Message: Logged In: YES user_id=45365 Aside from the patch david mentions (which probably fixes the bug in urllib2) pimp.py has also been updated as per your suggestion (rev. ---------------------------------------------------------------------- Comment By: David Lewis (davidmlewis) Date: 2003-05-02 22:18 Message: Logged In: YES user_id=626943 I filed a patch last night under 731151. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731115&group_id=5470 From noreply@sourceforge.net Fri May 2 21:30:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 13:30:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads Message-ID: Bugs item #539990, was opened at 2002-04-05 23:29 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: Wont Fix Priority: 7 Submitted By: Pieter Claerhout (pclaerhout) Assigned to: Just van Rossum (jvr) Summary: Framework.mainloop() - multiple threads Initial Comment: I tried to use the threading module to start the XML RPC server in a different thread (xmlrpcServer itself also is a threaded piece of code), but that seems to conflict with the mainloop. If you start this application, it starts the thread, starts the mainloop and stays in there, once you finish the mainloop, the thread continues. You've stumbled on a bug in Framework.mainloop(): it doesn't know anything about multiple threads. It gives time to other applications (by calling WaitNextEvent) but not to other threads within Python. Also see http://mail.python.org/pipermail/pythonmac-sig/2002- April/005416.html and http://mail.python.org/pipermail/pythonmac-sig/2002- April/005428.html ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-02 22:30 Message: Logged In: YES user_id=92689 Mac tree: somewhere in Mac/Modules/. It's a completely standalone module, it has no impact on the rest of the (Mac)Python source tree. PythonIDE.py would import it and call autoGIL.installAutoGIL(). You should have a look ;-) I'm playing with it now, and somehow it doesn't always quite work like I thought. Need to do more testing. It works perfectly in Cocoa apps, but not always under W/FrameWork's WaitNextEvent() loop. Don't know whether this is an inherent problem, but if so, that would be a reason to move to CarbonEvents pretty soon (assuming it _does_ work under CarbonEvt.RunApplicationEventLoop()). Hm. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 22:22 Message: Logged In: YES user_id=45365 What do you mean by "add it to the mac tree"? Anyway: I would love to have this functionality, but I think it is probably prudent to do development on a branch (unless you're pretty sure of it). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-02 20:28 Message: Logged In: YES user_id=92689 I finally got around playing with autoGIL in the IDE (briefly, though): it seems to work just fine! Reopeing this report. Jack, I could add autoGIL.c to the Mac tree if you want. A good experiment would be to make the PackagaManager threaded... ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2003-04-25 11:35 Message: Logged In: YES user_id=446428 Probably fixing this will also allow to run a long computation and still use the IDE for writing other code, or run commands in interactive mode. Sounds like a cool feature! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 11:43 Message: Logged In: YES user_id=45365 If that is true I would be very happy. Could you please investigate this and put it in if it works? Before 2.3b1 please: I don't want to mess with the core of the MacOS support modules after that... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-24 19:51 Message: Logged In: YES user_id=92689 Jack, have you forgotten about autoGIL? It's quite likely that the autoGIL module (as part of the PyObjC project) would fix this issue out of the box on OSX. Do "import autoGIL; autoGIL.installAutoGIL()" before you enter the event loop and the second thread gets time to run. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-24 17:45 Message: Logged In: YES user_id=45365 Let's admit this isn't going to be fixed unless someone wants it real bad. Pieter: if you want it real bad then reopen the bug and I'll find time for it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-22 16:03 Message: Logged In: YES user_id=45365 After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed. A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-07 23:26 Message: Logged In: YES user_id=45365 Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 From noreply@sourceforge.net Fri May 2 23:16:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 15:16:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-731626 ] Pimp needs to be able to update itself Message-ID: Bugs item #731626, was opened at 2003-05-03 00: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=731626&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Pimp needs to be able to update itself Initial Comment: Pimp needs a way to update itself. The version number in the database is good enough for backward compatibility (i.e. a newer pimp that happens upon an older database) but not for updating, I think (an older pimp that comes across a database that is too new). A possible solution would be analogous to what Apple does with Software Update: encode the pimp version number in the URL of the database, and when pimp is updated the old database is replaced by one that only offers one choice: upgrade pimp. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731626&group_id=5470 From noreply@sourceforge.net Fri May 2 23:32:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 15:32:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-731116 ] urllib2 raises AttributeError on redirect Message-ID: Bugs item #731116, was opened at 2003-05-02 04:48 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Raymond Hettinger (rhettinger) Summary: urllib2 raises AttributeError on redirect Initial Comment: The code import urllib2 f = urllib2.urlopen('http://www.cwi.nl/~jack/pimp/pimp-darwin-6.5- Power_Macintosh.plist') which is executed by pimp.py when the Macintosh PackageManager is initially brought up, raises an AttributeError when it gets redirected to homepages.cwi.nl. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-03 00:32 Message: Logged In: YES user_id=45365 And I attached the stack trace. ---------------------------------------------------------------------- Comment By: David Lewis (davidmlewis) Date: 2003-05-02 22:17 Message: Logged In: YES user_id=626943 I filed a patch under number 731153, if you want to review it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-02 21:09 Message: Logged In: YES user_id=80475 Please post the whole traceback. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 14:02 Message: Logged In: YES user_id=45365 The problem is a last-minute checkin before 2.3b1, rev 1.39. It refers to a method() method on requests which doesn't exist. Assigning to Raymond, as he did the checkin so he's the easiest scapegoat:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 From noreply@sourceforge.net Fri May 2 23:34:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 15:34:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-731631 ] OSX installer .pkg file permissions Message-ID: Bugs item #731631, was opened at 2003-05-03 00:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: OSX installer .pkg file permissions Initial Comment: The files installed by the OSX installer .pkg should be group writable. This goes both for the files installed in /Library/Frameworks/ Python.framework and /Applications/MacPython-2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470 From noreply@sourceforge.net Fri May 2 23:36:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 15:36:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads Message-ID: Bugs item #539990, was opened at 2002-04-05 23:29 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: Wont Fix Priority: 7 Submitted By: Pieter Claerhout (pclaerhout) Assigned to: Just van Rossum (jvr) Summary: Framework.mainloop() - multiple threads Initial Comment: I tried to use the threading module to start the XML RPC server in a different thread (xmlrpcServer itself also is a threaded piece of code), but that seems to conflict with the mainloop. If you start this application, it starts the thread, starts the mainloop and stays in there, once you finish the mainloop, the thread continues. You've stumbled on a bug in Framework.mainloop(): it doesn't know anything about multiple threads. It gives time to other applications (by calling WaitNextEvent) but not to other threads within Python. Also see http://mail.python.org/pipermail/pythonmac-sig/2002- April/005416.html and http://mail.python.org/pipermail/pythonmac-sig/2002- April/005428.html ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-03 00:36 Message: Logged In: YES user_id=45365 Ok, it is now clear that I didn't look at the end result of Mark Hammonds work, I thought it needed source modifications too. If it is just a module: by all means, check it in! And please add it to setup.py too (and either also add it to genpluginmodules.py and fullbuild.py, or assign this bug to me later). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-02 22:30 Message: Logged In: YES user_id=92689 Mac tree: somewhere in Mac/Modules/. It's a completely standalone module, it has no impact on the rest of the (Mac)Python source tree. PythonIDE.py would import it and call autoGIL.installAutoGIL(). You should have a look ;-) I'm playing with it now, and somehow it doesn't always quite work like I thought. Need to do more testing. It works perfectly in Cocoa apps, but not always under W/FrameWork's WaitNextEvent() loop. Don't know whether this is an inherent problem, but if so, that would be a reason to move to CarbonEvents pretty soon (assuming it _does_ work under CarbonEvt.RunApplicationEventLoop()). Hm. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 22:22 Message: Logged In: YES user_id=45365 What do you mean by "add it to the mac tree"? Anyway: I would love to have this functionality, but I think it is probably prudent to do development on a branch (unless you're pretty sure of it). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-02 20:28 Message: Logged In: YES user_id=92689 I finally got around playing with autoGIL in the IDE (briefly, though): it seems to work just fine! Reopeing this report. Jack, I could add autoGIL.c to the Mac tree if you want. A good experiment would be to make the PackagaManager threaded... ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2003-04-25 11:35 Message: Logged In: YES user_id=446428 Probably fixing this will also allow to run a long computation and still use the IDE for writing other code, or run commands in interactive mode. Sounds like a cool feature! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 11:43 Message: Logged In: YES user_id=45365 If that is true I would be very happy. Could you please investigate this and put it in if it works? Before 2.3b1 please: I don't want to mess with the core of the MacOS support modules after that... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-24 19:51 Message: Logged In: YES user_id=92689 Jack, have you forgotten about autoGIL? It's quite likely that the autoGIL module (as part of the PyObjC project) would fix this issue out of the box on OSX. Do "import autoGIL; autoGIL.installAutoGIL()" before you enter the event loop and the second thread gets time to run. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-24 17:45 Message: Logged In: YES user_id=45365 Let's admit this isn't going to be fixed unless someone wants it real bad. Pieter: if you want it real bad then reopen the bug and I'll find time for it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-22 16:03 Message: Logged In: YES user_id=45365 After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed. A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-07 23:26 Message: Logged In: YES user_id=45365 Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 From noreply@sourceforge.net Fri May 2 23:46:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 15:46:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads Message-ID: Bugs item #539990, was opened at 2002-04-05 23:29 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: Wont Fix Priority: 7 Submitted By: Pieter Claerhout (pclaerhout) Assigned to: Just van Rossum (jvr) Summary: Framework.mainloop() - multiple threads Initial Comment: I tried to use the threading module to start the XML RPC server in a different thread (xmlrpcServer itself also is a threaded piece of code), but that seems to conflict with the mainloop. If you start this application, it starts the thread, starts the mainloop and stays in there, once you finish the mainloop, the thread continues. You've stumbled on a bug in Framework.mainloop(): it doesn't know anything about multiple threads. It gives time to other applications (by calling WaitNextEvent) but not to other threads within Python. Also see http://mail.python.org/pipermail/pythonmac-sig/2002- April/005416.html and http://mail.python.org/pipermail/pythonmac-sig/2002- April/005428.html ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-03 00:46 Message: Logged In: YES user_id=92689 In case it wasn't clear: autoGIL is completely unrelated to Mark's work. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-03 00:36 Message: Logged In: YES user_id=45365 Ok, it is now clear that I didn't look at the end result of Mark Hammonds work, I thought it needed source modifications too. If it is just a module: by all means, check it in! And please add it to setup.py too (and either also add it to genpluginmodules.py and fullbuild.py, or assign this bug to me later). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-02 22:30 Message: Logged In: YES user_id=92689 Mac tree: somewhere in Mac/Modules/. It's a completely standalone module, it has no impact on the rest of the (Mac)Python source tree. PythonIDE.py would import it and call autoGIL.installAutoGIL(). You should have a look ;-) I'm playing with it now, and somehow it doesn't always quite work like I thought. Need to do more testing. It works perfectly in Cocoa apps, but not always under W/FrameWork's WaitNextEvent() loop. Don't know whether this is an inherent problem, but if so, that would be a reason to move to CarbonEvents pretty soon (assuming it _does_ work under CarbonEvt.RunApplicationEventLoop()). Hm. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 22:22 Message: Logged In: YES user_id=45365 What do you mean by "add it to the mac tree"? Anyway: I would love to have this functionality, but I think it is probably prudent to do development on a branch (unless you're pretty sure of it). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-02 20:28 Message: Logged In: YES user_id=92689 I finally got around playing with autoGIL in the IDE (briefly, though): it seems to work just fine! Reopeing this report. Jack, I could add autoGIL.c to the Mac tree if you want. A good experiment would be to make the PackagaManager threaded... ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2003-04-25 11:35 Message: Logged In: YES user_id=446428 Probably fixing this will also allow to run a long computation and still use the IDE for writing other code, or run commands in interactive mode. Sounds like a cool feature! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 11:43 Message: Logged In: YES user_id=45365 If that is true I would be very happy. Could you please investigate this and put it in if it works? Before 2.3b1 please: I don't want to mess with the core of the MacOS support modules after that... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-24 19:51 Message: Logged In: YES user_id=92689 Jack, have you forgotten about autoGIL? It's quite likely that the autoGIL module (as part of the PyObjC project) would fix this issue out of the box on OSX. Do "import autoGIL; autoGIL.installAutoGIL()" before you enter the event loop and the second thread gets time to run. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-24 17:45 Message: Logged In: YES user_id=45365 Let's admit this isn't going to be fixed unless someone wants it real bad. Pieter: if you want it real bad then reopen the bug and I'll find time for it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-22 16:03 Message: Logged In: YES user_id=45365 After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed. A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-07 23:26 Message: Logged In: YES user_id=45365 Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470 From noreply@sourceforge.net Fri May 2 23:58:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 15:58:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-731635 ] Package Manager needs Help menu Message-ID: Bugs item #731635, was opened at 2003-05-03 00: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=731635&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Package Manager needs Help menu Initial Comment: The standalone Package Manager needs a help menu, pointing to Package Manager section in MacPython help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731635&group_id=5470 From noreply@sourceforge.net Sat May 3 00:23:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 16:23:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-731643 ] IDE "lookup in documentation" doesn't work in interactive wi Message-ID: Bugs item #731643, was opened at 2003-05-03 01: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=731643&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: IDE "lookup in documentation" doesn't work in interactive wi Initial Comment: The Help->Lookup in Documentation picks up the selection in edit windows, but it doesn't do this in the Interactive window (and I wouldn't be surprised if it also doesn't work in the output window). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731643&group_id=5470 From noreply@sourceforge.net Sat May 3 00:23:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 16:23:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01: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=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 02:41:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 18:41:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-731689 ] typo in lib man - optparse Message-ID: Bugs item #731689, was opened at 2003-05-03 01: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=731689&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: typo in lib man - optparse Initial Comment: 2.3b1 Library Reference 6.20.3.3 option actions in the description of "append", '-tracks=4' should be changed to '--tracks=4' (two leading hyphen). Also '-tracsk=x' should be changed to '--tracks=x' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731689&group_id=5470 From noreply@sourceforge.net Sat May 3 02:48:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 18:48:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-731689 ] typo in lib man - optparse Message-ID: Bugs item #731689, was opened at 2003-05-03 01:41 Message generated for change (Comment added) made by inyeol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731689&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: typo in lib man - optparse Initial Comment: 2.3b1 Library Reference 6.20.3.3 option actions in the description of "append", '-tracks=4' should be changed to '--tracks=4' (two leading hyphen). Also '-tracsk=x' should be changed to '--tracks=x' ---------------------------------------------------------------------- >Comment By: Inyeol Lee (inyeol) Date: 2003-05-03 01:48 Message: Logged In: YES user_id=595280 one more type in the same page: In the description of "help", 'If optparse sees either --h or ..." -> 'If ... -h or ..." (--h to -h) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731689&group_id=5470 From noreply@sourceforge.net Sat May 3 06:16:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 22:16:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-728322 ] setup.py breaks during build of Python-2.3b1 Message-ID: Bugs item #728322, was opened at 2003-04-27 01:44 Message generated for change (Comment added) made by mikehsf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728322&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Ochiltree (joch1) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py breaks during build of Python-2.3b1 Initial Comment: I'm having trouble building Python-2.3b1 on SuSE 8.2. The ./configure didn't seem to object to anything but running the make bombs out with: running build running build_ext Traceback (most recent call last): File "./setup.py", line 1110, in ? main() File "./setup.py", line 1105, in main scripts = ['Tools/scripts/pydoc'] File "/home/johnoch/build/Python-2.3b1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 907, in run_commands self.run_command(cmd) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/command/build_ext.py", line 269, in run self.build_extensions() File "./setup.py", line 99, in build_extensions self.detect_modules() File "./setup.py", line 844, in detect_modules self.detect_tkinter(inc_dirs, lib_dirs) File "./setup.py", line 941, in detect_tkinter for dir in tcl_includes + tk_includes: TypeError: unsupported operand type(s) for +: 'NoneType' and 'list' make: *** [sharedmods] Error 1 I mentioned this on comp.lang.python and received the following from Martin v Lowis: It's a typo in setup.py. Replace if (tcllib is None or tklib is None and tcl_includes is None or tk_includes is None): # Something's missing, so give up return with if (tcllib is None or tklib is None or tcl_includes is None or tk_includes is None): # Something's missing, so give up return Alternatively, install the Tcl/Tk header files if you also want to build Tkinter. Please do report bugs at sf.net/projects/python in the future; a bug report in comp.lang.python will get lost. ---------------------------------------------------------------------- Comment By: Mike Harrison (mikehsf) Date: 2003-05-02 22:16 Message: Logged In: YES user_id=770566 There is a similar problem on line 448 of setup.py. Instead of if krb5_h: this should read something like: if krb5_h and ssl_links is not None: Mike Harrison 5/2/2003 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728322&group_id=5470 From noreply@sourceforge.net Sat May 3 06:38:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 02 May 2003 22:38:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-731689 ] typo in lib man - optparse Message-ID: Bugs item #731689, was opened at 2003-05-02 20:41 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731689&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) >Assigned to: Greg Ward (gward) Summary: typo in lib man - optparse Initial Comment: 2.3b1 Library Reference 6.20.3.3 option actions in the description of "append", '-tracks=4' should be changed to '--tracks=4' (two leading hyphen). Also '-tracsk=x' should be changed to '--tracks=x' ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-05-02 20:48 Message: Logged In: YES user_id=595280 one more type in the same page: In the description of "help", 'If optparse sees either --h or ..." -> 'If ... -h or ..." (--h to -h) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731689&group_id=5470 From noreply@sourceforge.net Sat May 3 10:02:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 02:02:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable Message-ID: Bugs item #731501, was opened at 2003-05-02 19:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Vargish (vargish) Assigned to: Skip Montanaro (montanaro) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:02 Message: Logged In: YES user_id=21627 I think this is not a bug. open() has determined that this is a bsddb file, but bsddb is not supported on the system. Or did you mean to suggest that opening the very same file with dbm would be successful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 From noreply@sourceforge.net Sat May 3 10:03:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 02:03:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 11:01:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:01:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-501716 ] "es#" parser marker leaks memory Message-ID: Bugs item #501716, was opened at 2002-01-10 11:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=501716&group_id=5470 Category: Unicode Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: "es#" parser marker leaks memory Initial Comment: ... if subsequent parsing fails, a buffer which was possibly allocated by "es#" is not freed. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 12:01 Message: Logged In: YES user_id=21627 Fixed in getargs.c 2.100 (with patch 684981). ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-12 00:11 Message: Logged In: YES user_id=670441 I submitted this as patch 684981 so it can be attached to the report instead of pasted in. Also, the patch there is nicer than the one here. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-10 21:37 Message: Logged In: YES user_id=670441 Ahhhh... thank you for your reply. I understand now. I have a patch that gets rid of this problem by putting allocated memory into a list of CObjects which are freed when exceptions occur. The list is only created when necessary, to hopefully preserve efficiency in most cases. It has to be passed around, so several function calls had to be changed, and to do the cleanup on return I made a macro CLEANRETURN. This patch also fixes a memory leak when the buffer_len pointer is NULL. This isn't a big deal since the documentation says never to pass in a NULL buffer_len. And it fixes another leak when a string with encoded NULL's is passed in (again not a big deal) If you want, I have C code that can be called from python to demonstrate any of these leaks. Let me know what you think of the patch/approach. Index: Python/getargs.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/getargs.c,v retrieving revision 2.95 diff -c -r2.95 getargs.c *** Python/getargs.c 24 Jan 2003 22:15:21 -0000 2.95 --- Python/getargs.c 10 Feb 2003 20:28:52 -0000 *************** *** 17,26 **** static int vgetargs1(PyObject *, char *, va_list *, int); static void seterror(int, char *, int *, char *, char *); static char *convertitem(PyObject *, char **, va_list *, int *, char *, ! size_t); static char *converttuple(PyObject *, char **, va_list *, ! int *, char *, size_t, int); ! static char *convertsimple(PyObject *, char **, va_list *, char *, size_t); static int convertbuffer(PyObject *, void **p, char **); static int vgetargskeywords(PyObject *, PyObject *, --- 17,27 ---- static int vgetargs1(PyObject *, char *, va_list *, int); static void seterror(int, char *, int *, char *, char *); static char *convertitem(PyObject *, char **, va_list *, int *, char *, ! size_t, PyObject **, int *); static char *converttuple(PyObject *, char **, va_list *, ! int *, char *, size_t, int, PyObject **, int *); ! static char *convertsimple(PyObject *, char **, va_list *, char *, ! size_t, PyObject **, int *); static int convertbuffer(PyObject *, void **p, char **); static int vgetargskeywords(PyObject *, PyObject *, *************** *** 72,77 **** --- 73,120 ---- } + /* Handle cleanup of allocated memory in case of exception */ + + static void + docleanup(void *ptr, void *dofree) + { + if (*(int *)dofree) + PyMem_FREE(ptr); + } + + static int + addcleanup(void *ptr, PyObject **freelist, int *dofree) + { + PyObject *cobj; + if (!*freelist) { + *freelist = PyList_New(0); + if (!*freelist) { + PyMem_FREE(ptr); + return -1; + } + } + cobj = PyCObject_FromVoidPtrAndDesc(ptr, dofree, docleanup); + if (!cobj) { + PyMem_FREE(ptr); + return -1; + } + if(PyList_Append(*freelist, cobj)) { + *dofree = 1; + Py_DECREF(cobj); + return -1; + } + Py_DECREF(cobj); + return 0; + } + + #define CLEANRETURN(retval, freelist, dofree) do \ + { \ + dofree = ((retval) == 0); \ + Py_XDECREF(freelist); \ + return (retval); \ + } while(0) + + static int vgetargs1(PyObject *args, char *format, va_list *p_va, int compat) { *************** *** 86,91 **** --- 129,136 ---- char *formatsave = format; int i, len; char *msg; + PyObject *freelist = NULL; + int dofree = 0; assert(compat || (args != (PyObject*)NULL)); *************** *** 157,167 **** return 0; } msg = convertitem(args, &format, p_va, levels, msgbuf, ! sizeof(msgbuf)); if (msg == NULL) ! return 1; seterror(levels[0], msg, levels+1, fname, message); ! return 0; } else { PyErr_SetString(PyExc_SystemError, --- 202,212 ---- return 0; } msg = convertitem(args, &format, p_va, levels, msgbuf, ! sizeof(msgbuf), &freelist, &dofree); if (msg == NULL) ! CLEANRETURN(1, freelist, dofree); seterror(levels[0], msg, levels+1, fname, message); ! CLEANRETURN(0, freelist, dofree); } else { PyErr_SetString(PyExc_SystemError, *************** *** 200,209 **** if (*format == '|') format++; msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va, ! levels, msgbuf, sizeof(msgbuf)); if (msg) { seterror(i+1, msg, levels, fname, message); ! return 0; } } --- 245,254 ---- if (*format == '|') format++; msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va, ! levels, msgbuf, sizeof(msgbuf), &freelist, &dofree); if (msg) { seterror(i+1, msg, levels, fname, message); ! CLEANRETURN(0, freelist, dofree); } } *************** *** 212,221 **** *format != '|' && *format != ':' && *format != ';') { PyErr_Format(PyExc_SystemError, "bad format string: %.200s", formatsave); ! return 0; } ! return 1; } --- 257,266 ---- *format != '|' && *format != ':' && *format != ';') { PyErr_Format(PyExc_SystemError, "bad format string: %.200s", formatsave); ! CLEANRETURN(0, freelist, dofree); } ! CLEANRETURN(1, freelist, dofree); } *************** *** 277,283 **** static char * converttuple(PyObject *arg, char **p_format, va_list *p_va, int *levels, ! char *msgbuf, size_t bufsize, int toplevel) { int level = 0; int n = 0; --- 322,329 ---- static char * converttuple(PyObject *arg, char **p_format, va_list *p_va, int *levels, ! char *msgbuf, size_t bufsize, int toplevel, ! PyObject **freelist, int *dofree) { int level = 0; int n = 0; *************** *** 327,333 **** PyObject *item; item = PySequence_GetItem(arg, i); msg = convertitem(item, &format, p_va, levels+1, msgbuf, ! bufsize); /* PySequence_GetItem calls tp->sq_item, which INCREFs */ Py_XDECREF(item); if (msg != NULL) { --- 373,379 ---- PyObject *item; item = PySequence_GetItem(arg, i); msg = convertitem(item, &format, p_va, levels+1, msgbuf, ! bufsize, freelist, dofree); /* PySequence_GetItem calls tp->sq_item, which INCREFs */ Py_XDECREF(item); if (msg != NULL) { *************** *** 345,351 **** static char * convertitem(PyObject *arg, char **p_format, va_list *p_va, int *levels, ! char *msgbuf, size_t bufsize) { char *msg; char *format = *p_format; --- 391,397 ---- static char * convertitem(PyObject *arg, char **p_format, va_list *p_va, int *levels, ! char *msgbuf, size_t bufsize, PyObject **freelist, int *dofree) { char *msg; char *format = *p_format; *************** *** 353,364 **** if (*format == '(' /* ')' */) { format++; msg = converttuple(arg, &format, p_va, levels, msgbuf, ! bufsize, 0); if (msg == NULL) format++; } else { ! msg = convertsimple(arg, &format, p_va, msgbuf, bufsize); if (msg != NULL) levels[0] = 0; } --- 399,411 ---- if (*format == '(' /* ')' */) { format++; msg = converttuple(arg, &format, p_va, levels, msgbuf, ! bufsize, 0, freelist, dofree); if (msg == NULL) format++; } else { ! msg = convertsimple(arg, &format, p_va, msgbuf, bufsize, ! freelist, dofree); if (msg != NULL) levels[0] = 0; } *************** *** 396,402 **** static char * convertsimple(PyObject *arg, char **p_format, va_list *p_va, char *msgbuf, ! size_t bufsize) { char *format = *p_format; char c = *format++; --- 443,449 ---- static char * convertsimple(PyObject *arg, char **p_format, va_list *p_va, char *msgbuf, ! size_t bufsize, PyObject **freelist, int *dofree) { char *format = *p_format; char c = *format++; *************** *** 801,810 **** int *buffer_len = va_arg(*p_va, int *); format++; ! if (buffer_len == NULL) return converterr( "(buffer_len is NULL)", arg, msgbuf, bufsize); if (*buffer == NULL) { *buffer = PyMem_NEW(char, size + 1); if (*buffer == NULL) { --- 848,859 ---- int *buffer_len = va_arg(*p_va, int *); format++; ! if (buffer_len == NULL) { ! Py_DECREF(s); return converterr( "(buffer_len is NULL)", arg, msgbuf, bufsize); + } if (*buffer == NULL) { *buffer = PyMem_NEW(char, size + 1); if (*buffer == NULL) { *************** *** 813,818 **** --- 862,873 ---- "(memory error)", arg, msgbuf, bufsize); } + if(addcleanup(*buffer, freelist, dofree)) { + Py_DECREF(s); + return converterr( + "(cleanup problem)", + arg, msgbuf, bufsize); + } } else { if (size + 1 > *buffer_len) { Py_DECREF(s); *************** *** 839,854 **** PyMem_Free()ing it after usage */ ! if ((int)strlen(PyString_AS_STRING(s)) != size) return converterr( "(encoded string without NULL bytes)", arg, msgbuf, bufsize); *buffer = PyMem_NEW(char, size + 1); if (*buffer == NULL) { Py_DECREF(s); return converterr("(memory error)", arg, msgbuf, bufsize); } memcpy(*buffer, PyString_AS_STRING(s), size + 1); --- 894,916 ---- PyMem_Free()ing it after usage */ ! if ((int)strlen(PyString_AS_STRING(s)) != size) { ! Py_DECREF(s); return converterr( "(encoded string without NULL bytes)", arg, msgbuf, bufsize); + } *buffer = PyMem_NEW(char, size + 1); if (*buffer == NULL) { Py_DECREF(s); return converterr("(memory error)", arg, msgbuf, bufsize); } + if(addcleanup(*buffer, freelist, dofree)) { + Py_DECREF(s); + return converterr("(cleanup problem)", + arg, msgbuf, bufsize); + } memcpy(*buffer, PyString_AS_STRING(s), size + 1); *************** *** 1068,1073 **** --- 1130,1137 ---- char *formatsave; int i, len, nargs, nkeywords; char *msg, **p; + PyObject *freelist = NULL; + int dofree = 0; assert(args != NULL && PyTuple_Check(args)); assert(keywords == NULL || PyDict_Check(keywords)); *************** *** 1192,1207 **** if (*format == '|') format++; msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va, ! levels, msgbuf, sizeof(msgbuf)); if (msg) { seterror(i+1, msg, levels, fname, message); ! return 0; } } /* handle no keyword parameters in call */ if (nkeywords == 0) ! return 1; /* convert the keyword arguments; this uses the format string where it was left after processing args */ --- 1256,1272 ---- if (*format == '|') format++; msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va, ! levels, msgbuf, sizeof(msgbuf), &freelist, ! &dofree); if (msg) { seterror(i+1, msg, levels, fname, message); ! CLEANRETURN(0, freelist, dofree); } } /* handle no keyword parameters in call */ if (nkeywords == 0) ! CLEANRETURN(1, freelist, dofree); /* convert the keyword arguments; this uses the format string where it was left after processing args */ *************** *** 1213,1235 **** if (item != NULL) { Py_INCREF(item); msg = convertitem(item, &format, p_va, levels, msgbuf, ! sizeof(msgbuf)); Py_DECREF(item); if (msg) { seterror(i+1, msg, levels, fname, message); ! return 0; } --nkeywords; if (nkeywords == 0) break; } else if (PyErr_Occurred()) ! return 0; else { msg = skipitem(&format, p_va); if (msg) { seterror(i+1, msg, levels, fname, message); ! return 0; } } } --- 1278,1300 ---- if (item != NULL) { Py_INCREF(item); msg = convertitem(item, &format, p_va, levels, msgbuf, ! sizeof(msgbuf), &freelist, &dofree); Py_DECREF(item); if (msg) { seterror(i+1, msg, levels, fname, message); ! CLEANRETURN(0, freelist, dofree); } --nkeywords; if (nkeywords == 0) break; } else if (PyErr_Occurred()) ! CLEANRETURN(0, freelist, dofree); else { msg = skipitem(&format, p_va); if (msg) { seterror(i+1, msg, levels, fname, message); ! CLEANRETURN(0, freelist, dofree); } } } *************** *** 1244,1250 **** if (!PyString_Check(key)) { PyErr_SetString(PyExc_TypeError, "keywords must be strings"); ! return 0; } ks = PyString_AsString(key); for (i = 0; i < max; i++) { --- 1309,1315 ---- if (!PyString_Check(key)) { PyErr_SetString(PyExc_TypeError, "keywords must be strings"); ! CLEANRETURN(0, freelist, dofree); } ks = PyString_AsString(key); for (i = 0; i < max; i++) { *************** *** 1258,1269 **** "'%s' is an invalid keyword " "argument for this function", ks); ! return 0; } } } ! return 1; } --- 1323,1334 ---- "'%s' is an invalid keyword " "argument for this function", ks); ! CLEANRETURN(0, freelist, dofree); } } } ! CLEANRETURN(1, freelist, dofree); } ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-08 15:29 Message: Logged In: YES user_id=38388 What I meant was that in the case of a parser marker string like "es#iii" if the last "i" fails to convert, then the buffer used for "es#" won't be freed up again. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-07 21:20 Message: Logged In: YES user_id=670441 In what case does this happen? The only case I can see is if the string is successfully encoded, but the encoding results in a non-null terminated string. That might cause problems, otherwise it looks okay? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=501716&group_id=5470 From noreply@sourceforge.net Sat May 3 11:09:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:09:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-678250 ] test_mmap failling on AIX Message-ID: Bugs item #678250, was opened at 2003-01-31 18:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Nobody/Anonymous (nobody) Summary: test_mmap failling on AIX Initial Comment: test_mmap is failing on a flush while trying to do: Copy-on-write memory map data not written correctly The problem is that the mmap is opened with ACCESS_COPY. This translates to MAP_PRIVATE. On AIX, the msync man page says: "When the MS_SYNC and MAP_PRIVATE flags both are used, the msync subroutine returns an errno value of EINVAL." I'm not sure what the correct fix should be. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=21627 The documentation for flush says "Flushes changes made to the in-memory copy of a file back to disk." But it doesn't do that, and we all agree it shouldn't do that. So I would claim that it is an error to use .flush on an mmap object that was opened in ACCESS_COPY. This is like trying to write to a file that was opened for reading only: one *could* declare that the write just does nothing, but it helps the developer more if you get an exception, because the code is likely wrong (i.e. not following the likely intentions of the author). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-28 21:55 Message: Logged In: YES user_id=31435 Sorry, I've had nothing to do with mmap beyond fixing bugs. The "access" feature was due to Jay Miller, although I believe I checked in his patch. Martin, I don't understand why you think it's reasonable for flush to complain here: the mmap is open for writing, so what's surprising about expecting to be able to flush after a write? Simply that there's no associated file, due to copy-on- write? Then user code would have to be acutely aware of how an mmap'ed object was opened, just to avoid nuisance complaints when they flush after writing. So that's a third alternative: alter the implementation to make mmap.flush() do nothing when an mmap object was opened as copy-on-write. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 08:00 Message: Logged In: YES user_id=21627 I think the test is somewhat bogus: It tries to check that modification to an ACCESS_COPY doesn't modify the underlying file, but assumes that .flush becomes a no-op, even though an exception is more reasonable (IMO; errors should never pass silently). So I see two options: Declare that .flush() always raises an exception (and modify implementations that don't produce an exception accordingly), or declare that aspect to be system-dependent, and modify the test (and the documentation) to expect and ignore an exception. Assigning to Tim, as he incorporated that feature into mmap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 From noreply@sourceforge.net Sat May 3 11:09:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:09:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 11:13:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:13:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-724588 ] socketmodule doesn't compile on strict POSIX systems Message-ID: Bugs item #724588, was opened at 2003-04-20 14:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724588&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Martin v. Löwis (loewis) Summary: socketmodule doesn't compile on strict POSIX systems Initial Comment: socketmodule uses the functions: - hstrerror - inet_aton - inet_pton and definitions: - NI_MAXHOST - NI_MAXSERV which aren't defined by IEEE Std 1003.1, 2003 Edition (regarding to http://www.unix.org/single_unix_specification/). The attached patch changes configure.in so that configure tries to take the adress of the functions rather than the autoconf library function check. Because with the later the POSIX/POSIX_C_SOURCE/XOPEN etc definitions are not set. It also changes socketmodule.c to define NI_MAXHOST and NI_MAXSERV if they haven't been defined already. This fixes compilation of socketmodule on: NetBSD 1.6R i386 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 12:13 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.391 configure.in 1.402 pyconfig.h.in 1.77 socketmodule.c 1.264 ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-04-20 15:43 Message: Logged In: YES user_id=205 This is for Python 2.3/CVS (20.04.2003). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724588&group_id=5470 From noreply@sourceforge.net Sat May 3 11:13:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 03:13:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-678264 ] test_resource fails when file size is limited Message-ID: Bugs item #678264, was opened at 2003-01-31 19:06 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_resource fails when file size is limited Initial Comment: test_resource does: print resource.RLIM_INFINITY == max I'm not sure of the benefit of this line. For machines which have limited file sizes, it causes the test to fail. Otherwise the test seems to work properly. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 22:49 Message: Logged In: YES user_id=21627 I'm really not that much concerned about fixing the test, but more about fixing the code itself. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-30 22:25 Message: Logged In: YES user_id=33168 Hmmm, sounds like a lot of work. How about something like this: expected_max = resource.RLIM_INFINITY if expected_max != max: # read the file resource limit fsize_ulimit = os.popen('ulimit -f').read() try: # convert the file size to bytes (from 512 byte blocks) expected_max = int(fsize_ulimit.strip()) * 512 except ValueError: raise TestSkipped, "unable to determine expected resource value" print expected_max == max This works, but I'm pretty sure this is not portable. On Linux blocks are 1k. This only works when the block size is 512 bytes. Shall we close this bug as a test environment problem and won't fix? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 18:15 Message: Logged In: YES user_id=21627 The rationale of the line is explained in the comment: The code tests whether the limit is a really large number, i.e. whether represenation of large limits works. Unfortunately, it doesn't (which is a separate issue): On Linux, RLIM_INFINITY is reported as -1. This comes from RLIM_INFINITY being the larges unsigned long long number, i.e. 0xffffffffffffffffuLL. The resource module represents this incorrectly. I think there is no way to verify that Python computes the real limit correctly (unless we invoke the shell's ulimit for comparison). So you could weaken the test to verify that the limit is non-negative (and, as a side effect, verify that it doesn't raise an exception). If you do so, you'll also have to fix the implementation, so that the weakened-strengthened test passes on Linux. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 23:17 Message: Logged In: YES user_id=33168 Martin, welcome back! Now I get to assign some bugs to you to see if you have any input. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470 From noreply@sourceforge.net Sat May 3 12:28:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 04:28:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-727051 ] valgrind python fails Message-ID: Bugs item #727051, was opened at 2003-04-24 19:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: valgrind python fails Initial Comment: Platform: Redhat 7.3 on Intel Xeon Packages involved: valgrind-1.9.5 (http://developer.kde.org/~sewardj/) Python CVS snapshot Thu Apr 24 10:00:00 PDT 2003 valgrind python fails with the following message: % valgrind python python: relocation error: /lib/librt.so.1: symbol __pthread_clock_settime, version GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference This is with: % python Python 2.3b1 (#1, Apr 24 2003, 10:20:26) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> I observed the same problem with Python 2.3a2. There are no problems when using Python 2.2.1 on the exact same platform with the same valgrind installation. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 13:28 Message: Logged In: YES user_id=21627 This is fixed with 73017 patch in configure 1.393 configure.in 1.404 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-04-30 11:31 Message: Logged In: YES user_id=4771 I figured it out. 'configure.in' now looks in various libraries for the sem_init() function (it is in different libs on different platforms); more precisely, it searches in librt and libposix4. However, on Linux, for some reason it is also defined in libpthread which is always linked with Python (unless one disables threads, of course). As a suggested fix, I'd say that configure.in should first look for sem_init in libpthread. That way, the Linux compilation won't be linked against the unneeded and valgrind-conflicting librt at all. I can provide a patch that does this. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-04-29 22:49 Message: Logged In: YES user_id=71407 > Is it worth any further investigation ? If not, close this > bug track. valgrind is extremely useful. It seems very important to me that Python 2.3 works with valgrind out-of-the-box, just like Python 2.2 does. I'm afraid otherwise "Why doesn't Python work with valgrind?" is going to wind up in the Python FAQ. > What I cannot understand is the purpose of binding against > that library on Linux. It ends up in the Makefile for some > indirect reason. I tried without it and the 'make test' > works just fine. I'd be very glad if you could find ways of not binding against librt.so if it is not needed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-04-29 21:06 Message: Logged In: YES user_id=4771 This is documented as a known problem with the librt.so library on http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt. What I cannot understand is the purpose of binding against that library on Linux. It ends up in the Makefile for some indirect reason. I tried without it and the 'make test' works just fine. Is it worth any further investigation ? If not, close this bug track. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-24 21:14 Message: Logged In: YES user_id=33168 I think I got around this problem by adding: void __pthread_clock_settime() { } I think this may be mentioned in the valgrind FAQ/doc. Or perhaps, it's something similar which I am confusing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727051&group_id=5470 From noreply@sourceforge.net Sat May 3 13:18:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 05:18:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 13:30:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 05:30:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 09:23 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-05-03 22:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 22:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 20:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 19:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 14:40:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 06:40:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:40 Message: Logged In: YES user_id=92689 Since my platform is BSD-ish, I want a lock ;-) Yes, I would like to work on a patch, except I will need some hand-holding, as I've never done anything with threads from C. Can you point me to examples of such a lock in the Python source code? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-03 14:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 14:56:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 06:56:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:56 Message: Logged In: YES user_id=92689 (Never mind, I found plenty of examples in sockemodule.c itself.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:40 Message: Logged In: YES user_id=92689 Since my platform is BSD-ish, I want a lock ;-) Yes, I would like to work on a patch, except I will need some hand-holding, as I've never done anything with threads from C. Can you point me to examples of such a lock in the Python source code? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-03 14:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 15:00:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 07:00:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 16:00 Message: Logged In: YES user_id=21627 Mark: the original complaint came from BSD users. So if we only release the GIL on a "good" platform, the BSD users aren't helped. Likewise, unless compiled by VC7.x, Windows users are not helped, since Python would use the getaddrinfo emulation. So if this as attempted, I think we need a best-effort solution for all systems. You could look at the Tcl lock. I recommend you look at the 2.2 sources, since the Tcl lock logic got more complicated recently (as Tcl now also has a multi-threaded mode of operation). If your platform is Mac OS X, don't trust that it is too BSDish in this respect. If both FreeBSD and NeXT had some function, Apple apparently has always chosen the NeXT version. getaddrinfo was one such case. But then, it appears that the NeXT version is even worse than the FreeBSD version. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:56 Message: Logged In: YES user_id=92689 (Never mind, I found plenty of examples in sockemodule.c itself.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:40 Message: Logged In: YES user_id=92689 Since my platform is BSD-ish, I want a lock ;-) Yes, I would like to work on a patch, except I will need some hand-holding, as I've never done anything with threads from C. Can you point me to examples of such a lock in the Python source code? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-03 14:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 16:18:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 08:18:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-727137 ] use bsddb185 if necessary in dbhash Message-ID: Bugs item #727137, was opened at 2003-04-24 21:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: use bsddb185 if necessary in dbhash Initial Comment: I've had this patch sitting around for awhile. I think if the new bsddb stuff can't be built and the user enables the bsddb185 module in Modules/Setup that dbhash should also try that module when setting things up. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 17:18 Message: Logged In: YES user_id=21627 -1. I think users should make an explicit decision to use bsddb 1.85, and should get an error if they use any of the libraries on top of it. The only reasonable exception might be whichdb, which could say 'bsddb185', if it recognizes the file format. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470 From noreply@sourceforge.net Sat May 3 19:02:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 11:02:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-03 20:02 Message: Logged In: YES user_id=92689 I've attached a first cut of a patch. It implements wrappers for getaddrinfo and getnameinfo, to take the burden of dealing with the lock and the GIL away from the caller. As suggested by MvL in prvt mail, I've simply reused the existing gethostbyname lock, but renamed it to netdb_lock. What needs to be reviewed carefully is when exactly USE_NETDB_LOCK (formerly known as USE_GETHOSTBYNAME_LOCK) is defined. It happens to be defined for my platform, so it "works for me". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 16:00 Message: Logged In: YES user_id=21627 Mark: the original complaint came from BSD users. So if we only release the GIL on a "good" platform, the BSD users aren't helped. Likewise, unless compiled by VC7.x, Windows users are not helped, since Python would use the getaddrinfo emulation. So if this as attempted, I think we need a best-effort solution for all systems. You could look at the Tcl lock. I recommend you look at the 2.2 sources, since the Tcl lock logic got more complicated recently (as Tcl now also has a multi-threaded mode of operation). If your platform is Mac OS X, don't trust that it is too BSDish in this respect. If both FreeBSD and NeXT had some function, Apple apparently has always chosen the NeXT version. getaddrinfo was one such case. But then, it appears that the NeXT version is even worse than the FreeBSD version. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:56 Message: Logged In: YES user_id=92689 (Never mind, I found plenty of examples in sockemodule.c itself.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:40 Message: Logged In: YES user_id=92689 Since my platform is BSD-ish, I want a lock ;-) Yes, I would like to work on a patch, except I will need some hand-holding, as I've never done anything with threads from C. Can you point me to examples of such a lock in the Python source code? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-03 14:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 20:17:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 12:17:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-731689 ] typo in lib man - optparse Message-ID: Bugs item #731689, was opened at 2003-05-02 21:41 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731689&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Greg Ward (gward) Summary: typo in lib man - optparse Initial Comment: 2.3b1 Library Reference 6.20.3.3 option actions in the description of "append", '-tracks=4' should be changed to '--tracks=4' (two leading hyphen). Also '-tracsk=x' should be changed to '--tracks=x' ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2003-05-03 15:17 Message: Logged In: YES user_id=14422 OK, should be fixed in CVS (rev 1.3 of Doc/lib/liboptparse.tex). ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-05-02 21:48 Message: Logged In: YES user_id=595280 one more type in the same page: In the description of "help", 'If optparse sees either --h or ..." -> 'If ... -h or ..." (--h to -h) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731689&group_id=5470 From noreply@sourceforge.net Sat May 3 21:17:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 13:17:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-727137 ] use bsddb185 if necessary in dbhash Message-ID: Bugs item #727137, was opened at 2003-04-24 14:56 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: use bsddb185 if necessary in dbhash Initial Comment: I've had this patch sitting around for awhile. I think if the new bsddb stuff can't be built and the user enables the bsddb185 module in Modules/Setup that dbhash should also try that module when setting things up. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-03 15:17 Message: Logged In: YES user_id=44345 There are valid reasons why people don't update their db library. The most obvious one that occurs to me is that the system itself stores files with that version of the library which applications need to read (I remember the pwd module had this problem at one time. Probably still does under the correct circumstances.) As for whichdb returning "bsddb185", that can only happen if we are willing to an "open" method to it. Even then, whichdb will probably have to be made more discriminating (distinguishing files readable via db 1.85 ("bsddb185") and files readable by more recent versions ("dbhash"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 10:18 Message: Logged In: YES user_id=21627 -1. I think users should make an explicit decision to use bsddb 1.85, and should get an error if they use any of the libraries on top of it. The only reasonable exception might be whichdb, which could say 'bsddb185', if it recognizes the file format. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470 From noreply@sourceforge.net Sat May 3 22:20:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 14:20:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-727137 ] use bsddb185 if necessary in dbhash Message-ID: Bugs item #727137, was opened at 2003-04-24 21:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: use bsddb185 if necessary in dbhash Initial Comment: I've had this patch sitting around for awhile. I think if the new bsddb stuff can't be built and the user enables the bsddb185 module in Modules/Setup that dbhash should also try that module when setting things up. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 23:20 Message: Logged In: YES user_id=21627 I agree that people will want to use bsddb185 to open existing files, and we should make this readily available. At the same, we should not provide easy means to create new files. So I suggest to reject this patch: If anything is done about dbhash, it should check, on open, what version of the database library needs to be used to open an existing file. It is indeed the case that the current whichdb implementation is not capable of distinguishing BSDB on-disk format versions. Such version information is available inside the file, and it would be possible to teach whichdb about that. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-03 22:17 Message: Logged In: YES user_id=44345 There are valid reasons why people don't update their db library. The most obvious one that occurs to me is that the system itself stores files with that version of the library which applications need to read (I remember the pwd module had this problem at one time. Probably still does under the correct circumstances.) As for whichdb returning "bsddb185", that can only happen if we are willing to an "open" method to it. Even then, whichdb will probably have to be made more discriminating (distinguishing files readable via db 1.85 ("bsddb185") and files readable by more recent versions ("dbhash"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 17:18 Message: Logged In: YES user_id=21627 -1. I think users should make an explicit decision to use bsddb 1.85, and should get an error if they use any of the libraries on top of it. The only reasonable exception might be whichdb, which could say 'bsddb185', if it recognizes the file format. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470 From noreply@sourceforge.net Sat May 3 22:45:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 14:45:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 23:45 Message: Logged In: YES user_id=21627 The patch is incorrect: usage of locked getaddrinfo depends on whether gethostbyname_r is supported on the platform. However, this is unrelated: A platform may have gethostbyname_r, and still not provide a thread-safe getaddrinfo, or it may not have gethostbyname_r, and yet provide a thread-safe getaddrinfo. I suggest you separate issues: 1. Should the lock variable be declared and initialized? You have two options: a) only create if needed (see below), or b) always create if Python is threaded 2. Should getaddrinfo use the lock? In general, it shouldn't, except for a few known-bad systems. 3. Should gethostbyname use the lock? Yes, unless the reentrant versions of this function are used. Notice that for Windows, gethostbyname itself is thread-safe, as it allocates a thread-local hostent. I think the lock management code is also incorrect: There is a certain moment after getaddrinfo returns where neither the GIL nor the getaddrinfo lock is held, yet Python accesses the getaddrinfo result afterwards. If getaddrinfo returns a pointer to global data, a second call could modify the result even though we have not processed it yet. I'm not sure how to solve this. It is probably safest to keep the getaddrinfo lock until freeaddrinfo has been called. Also, for systems that don't lock getaddrinfo, I would prefer if py_getaddrinfo was a define for getaddrinfo. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 20:02 Message: Logged In: YES user_id=92689 I've attached a first cut of a patch. It implements wrappers for getaddrinfo and getnameinfo, to take the burden of dealing with the lock and the GIL away from the caller. As suggested by MvL in prvt mail, I've simply reused the existing gethostbyname lock, but renamed it to netdb_lock. What needs to be reviewed carefully is when exactly USE_NETDB_LOCK (formerly known as USE_GETHOSTBYNAME_LOCK) is defined. It happens to be defined for my platform, so it "works for me". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 16:00 Message: Logged In: YES user_id=21627 Mark: the original complaint came from BSD users. So if we only release the GIL on a "good" platform, the BSD users aren't helped. Likewise, unless compiled by VC7.x, Windows users are not helped, since Python would use the getaddrinfo emulation. So if this as attempted, I think we need a best-effort solution for all systems. You could look at the Tcl lock. I recommend you look at the 2.2 sources, since the Tcl lock logic got more complicated recently (as Tcl now also has a multi-threaded mode of operation). If your platform is Mac OS X, don't trust that it is too BSDish in this respect. If both FreeBSD and NeXT had some function, Apple apparently has always chosen the NeXT version. getaddrinfo was one such case. But then, it appears that the NeXT version is even worse than the FreeBSD version. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:56 Message: Logged In: YES user_id=92689 (Never mind, I found plenty of examples in sockemodule.c itself.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:40 Message: Logged In: YES user_id=92689 Since my platform is BSD-ish, I want a lock ;-) Yes, I would like to work on a patch, except I will need some hand-holding, as I've never done anything with threads from C. Can you point me to examples of such a lock in the Python source code? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-03 14:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Sat May 3 22:57:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 14:57:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-713722 ] Distutils documentation amputated Message-ID: Bugs item #713722, was opened at 2003-04-02 06:27 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713722&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Ewing (gcewing) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils documentation amputated Initial Comment: Somewhere between the 2.0 and 2.1 documentation releases, a big chunk of the Distributing Python Modules manual seems to have gone missing. Section 7 (Examples), 8 (Extending the Distutils) and most of 9 (Reference) are absent. Section 7 contains a small part of what used to be section 9. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-03 21:57 Message: Logged In: YES user_id=31392 Can you be specific about what text was lost? That is, what revision of dist.tex contains the text that is missing? If I look at the 2.0 release documentation, I see an empty section named "Extending the distutils." I don't think there was ever any text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713722&group_id=5470 From noreply@sourceforge.net Sun May 4 05:12:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 21:12:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-732057 ] stdout.softspace no longer writable Message-ID: Bugs item #732057, was opened at 2003-05-04 00: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=732057&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: stdout.softspace no longer writable Initial Comment: >>> import sys >>> sys.stdout.softspace = 0 Traceback (most recent call last): File "", line 1, in ? TypeError: 'file' object has only read-only attributes (assign to .softspace) >>> Offhand this is a mystery. file_memberlist's entry for softspace does not mark it readonly ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732057&group_id=5470 From noreply@sourceforge.net Sun May 4 05:13:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 03 May 2003 21:13:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-732057 ] stdout.softspace no longer writable Message-ID: Bugs item #732057, was opened at 2003-05-04 00:12 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732057&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: stdout.softspace no longer writable Initial Comment: >>> import sys >>> sys.stdout.softspace = 0 Traceback (most recent call last): File "", line 1, in ? TypeError: 'file' object has only read-only attributes (assign to .softspace) >>> Offhand this is a mystery. file_memberlist's entry for softspace does not mark it readonly ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-04 00:13 Message: Logged In: YES user_id=31435 The file object had a NULL tp_setattro slot. Repaired, and added new tests to test_file.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732057&group_id=5470 From noreply@sourceforge.net Sun May 4 10:56:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 02:56:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-732120 ] An extended definition of "non-overlapping" would save time. Message-ID: Bugs item #732120, was opened at 2003-05-04 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=732120&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Philip Jägenstedt (foolip) Assigned to: Nobody/Anonymous (nobody) Summary: An extended definition of "non-overlapping" would save time. Initial Comment: Hello. Yesterday I spent several hours trying to figure out why a (stupid) regex like "^|foo" didn't return ['', 'foo'] for findall("foo"). Like this: |f|o|o| 0 1 2 3 I figured the ^ would match 0-0 and then a 0-3 match for foo. I've learnt since that the reason this can't happen is because the regexp engine would get caught in an infinte loop. However, the two matches aren't really overlapping, and the docs state that all non-overlapping matches would be returned. I suggest therefor that it is clarified in the docs that non-overlapping doesn't apply to a zero-length match at the beginning of another potential match. This would apply to findall and finditer in doc/python2.2/html/lib/node99.html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732120&group_id=5470 From noreply@sourceforge.net Sun May 4 11:03:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 03:03:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-732124 ] Clarification of "pos" and "endpos" for match objects. Message-ID: Bugs item #732124, was opened at 2003-05-04 12: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=732124&group_id=5470 Category: Documentation Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Philip Jägenstedt (foolip) Assigned to: Nobody/Anonymous (nobody) Summary: Clarification of "pos" and "endpos" for match objects. Initial Comment: In doc/python2.2/html/lib/match-objects.html the following is stated: pos The value of pos which was passed to the search() or match() function. ... endpos The value of endpos which was passed to the search() or match() function. ... I was confused for quite a while when I couldn't see a pos or endpos argument in the docs for match() in the re module. The said arguments exist only for "4.2.4 Regular Expression Objects", so I would suggest that it is clarified in the match-object docs when the pos and endpos members are available. I guess that would mean writing "procedure" instead of "function" too, but more importantly, a formulation like "The value of pos which was passed to the search() or match() procedure of the regexp object" That is all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732124&group_id=5470 From noreply@sourceforge.net Sun May 4 13:33:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:33:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-730467 ] Not detecting AIX_GENUINE_CPLUSPLUS Message-ID: Bugs item #730467, was opened at 2003-05-01 00:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730467&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Patrick Miller (patmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Not detecting AIX_GENUINE_CPLUSPLUS Initial Comment: PYthon2.2.2 and Python2.3 AIX xlC Need to update the code in configure.in to remove the hardcoded path for load where we detect AIX_GENUINE_CPLUSPLUS The current version looks for /usr/lpp/xlC/include/load.h but it should just use Without it, Python uses load() for dynamic load instead of loadAndInit() in dynload_aix.c Patch attached # checks for system dependent C++ extensions support case "$ac_sys_system" in AIX*) AC_MSG_CHECKING(for genuine AIX C++ extensions support) AC_TRY_LINK([#include "], [loadAndInit("", 0, "")], [AC_DEFINE(AIX_GENUINE_CPLUSPLUS) AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no)]);; *) ;; esac ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:33 Message: Logged In: YES user_id=21627 When you say "update", do you mean that the code was correct for earlier versions of some software (which versions of which software?), and is now incorrect? With the proposed change, will the new code still run on the old versions of the software? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730467&group_id=5470 From noreply@sourceforge.net Sun May 4 13:36:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:36:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 19:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply@sourceforge.net Sun May 4 13:39:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:39:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Sun May 4 13:40:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:40:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-728322 ] setup.py breaks during build of Python-2.3b1 Message-ID: Bugs item #728322, was opened at 2003-04-27 10:44 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728322&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Ochiltree (joch1) >Assigned to: Martin v. Löwis (loewis) Summary: setup.py breaks during build of Python-2.3b1 Initial Comment: I'm having trouble building Python-2.3b1 on SuSE 8.2. The ./configure didn't seem to object to anything but running the make bombs out with: running build running build_ext Traceback (most recent call last): File "./setup.py", line 1110, in ? main() File "./setup.py", line 1105, in main scripts = ['Tools/scripts/pydoc'] File "/home/johnoch/build/Python-2.3b1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 907, in run_commands self.run_command(cmd) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/command/build_ext.py", line 269, in run self.build_extensions() File "./setup.py", line 99, in build_extensions self.detect_modules() File "./setup.py", line 844, in detect_modules self.detect_tkinter(inc_dirs, lib_dirs) File "./setup.py", line 941, in detect_tkinter for dir in tcl_includes + tk_includes: TypeError: unsupported operand type(s) for +: 'NoneType' and 'list' make: *** [sharedmods] Error 1 I mentioned this on comp.lang.python and received the following from Martin v Lowis: It's a typo in setup.py. Replace if (tcllib is None or tklib is None and tcl_includes is None or tk_includes is None): # Something's missing, so give up return with if (tcllib is None or tklib is None or tcl_includes is None or tk_includes is None): # Something's missing, so give up return Alternatively, install the Tcl/Tk header files if you also want to build Tkinter. Please do report bugs at sf.net/projects/python in the future; a bug report in comp.lang.python will get lost. ---------------------------------------------------------------------- Comment By: Mike Harrison (mikehsf) Date: 2003-05-03 07:16 Message: Logged In: YES user_id=770566 There is a similar problem on line 448 of setup.py. Instead of if krb5_h: this should read something like: if krb5_h and ssl_links is not None: Mike Harrison 5/2/2003 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728322&group_id=5470 From noreply@sourceforge.net Sun May 4 13:40:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:40:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-728277 ] Tools/msgfmt.py results in two warnings under Python 2.3b1 Message-ID: Bugs item #728277, was opened at 2003-04-27 05:35 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728277&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) >Assigned to: Martin v. Löwis (loewis) Summary: Tools/msgfmt.py results in two warnings under Python 2.3b1 Initial Comment: Running Tools/msgfmt.py under Python 2.3b1 (also the alphas) results in the following warnings: [sdeibel@hedgehog build-files]$ python2.3 ~/src/Python-2.3b1/Tools/i18n/msgfmt.py --help sys:1: DeprecationWarning: Non-ASCII character '\xf6' in file /home/sdeibel/src/Python-2.3b1/Tools/i18n/msgfmt.py on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details /home/sdeibel/src/Python-2.3b1/Tools/i18n/msgfmt.py:86: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up 0x950412de, # Magic Doesn't cause any problems but would be cleaner to add encoding info and the 'L' for the constant. This is on Mandrake 8.2 but I'm sure it happens everywhere. - Stephan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728277&group_id=5470 From noreply@sourceforge.net Sun May 4 13:42:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:42:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball Message-ID: Bugs item #728051, was opened at 2003-04-26 16:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: Test failures on Linux, Python 2.3b1 tarball Initial Comment: "make test" resulted in: test test_tempfile failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test test_time failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/Python-2.3b1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:42 Message: Logged In: YES user_id=21627 What operating system distribution specifically did you use? What C library does this system use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 From noreply@sourceforge.net Sun May 4 13:43:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:43:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-727732 ] getpath.c-generated prefix wrong for Tru64 scripts Message-ID: Bugs item #727732, was opened at 2003-04-25 21:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727732&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: getpath.c-generated prefix wrong for Tru64 scripts Initial Comment: Under Tru64 (version 5.1a, and probably others), when a Python script is structured like so: #!/something/bin/python import sys print sys.prefix the calculation of prefix in getpath.c won't work correctly. The reason is that argv[0] will be 'python' rather than '/something/bin/python' (as it would be under, say, Linux). The code happens to work correctly in some simple scenarios, but fails in a pretty mysterious way if one has a different python in one's PATH than the one in the #! line. So, for example, if my PATH=/usr/bin and there is a /usr/bin/python, then if I run the script above, sys.prefix will be set to '/usr' instead of '/something' and the wrong module path will be set up, etc. It would be much better to simply obey the compiled PREFIX instead, at least in the case where argv[0] has no slashes. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:43 Message: Logged In: YES user_id=21627 Is there any way for a binary to find out its location on disk, on Tru64? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727732&group_id=5470 From noreply@sourceforge.net Sun May 4 13:50:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:50:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-717614 ] Uthread problem - Pipe left open Message-ID: Bugs item #717614, was opened at 2003-04-08 18:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717614&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jim Ramsay (lack) Assigned to: Nobody/Anonymous (nobody) Summary: Uthread problem - Pipe left open Initial Comment: For some reason on my FreeBSD system whenever I run python I am unable to access file descriptor 3 or 4. According to my system's fstat, there is a pipe there: lack python 36683 3* pipe cd5b2cc0 <-> cd99f9e0 0 rw lack python 36683 4* pipe cd99f9e0 <-> cd5b2cc0 0 rw But I did not open this pipe, nor can I figure out where it came from. I also cannot close this file descriptor or use it in any way - I recieve the error: >>> os.close(3) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 9] Bad file descriptor >>> There is some strange behaviour if I close one of the standard descriptors first: >>> os.close(2) >>> os.close(3) >>> os.close(4) >>> But despite the lack of error messages, the pipe from 3 to 4 is still open. I do not know why this happens. and am at a loss at how to access FD#3. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:50 Message: Logged In: YES user_id=21627 Neither uthread_init.c nor uthread_execve.c are part of the Python distribution. Why do you think you have found a bug in Python? It sounds more like a bug in FreeBSD to me. ---------------------------------------------------------------------- Comment By: Jim Ramsay (lack) Date: 2003-04-08 19:30 Message: Logged In: YES user_id=185022 Update: This seems to be linked to "uthread" support. This pipe is opened in uthread_init.c around line 167, and should be closed by uthread_execve.c around line 59. For some reason the pipe is not being closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717614&group_id=5470 From noreply@sourceforge.net Sun May 4 13:53:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:53:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-712056 ] OpenBSD 3.2: make altinstall dumps core Message-ID: Bugs item #712056, was opened at 2003-03-30 05:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD 3.2: make altinstall dumps core Initial Comment: "make altinstall" fails when building on OpenBSD 3.2. The core dump appears to happen when the newly built python program attempts to byte-compile "./Lib/test/test_pep263.py". A gdb 'bt' shows a segmentation fault in a call to libiconv.so.3.0's div() function. This could be a bug in libiconv.so's unicode handling. Also, running "./python ./Lib/test/test_pep263.py" from the newly built python throws an assertation error. I am using a home-built version of OpenBSD, so I'd appreciate it if someone else could verify this. make altinstall's output: ... Compiling /usr/local/lib/python2.3/test/test_pep263.py ... python in free(): warning: modified (chunk-) pointer. python in free(): warning: modified (chunk-) pointer. python in free(): warning: modified (chunk-) pointer. Memory fault (core dumped) *** Error code 139 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:53 Message: Logged In: YES user_id=21627 I assume this is fixed now, since the iconv module has been removed from Python. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-03-31 09:11 Message: Logged In: YES user_id=699438 It's using 'ucs-2-internal' for it's UNICODE_ENCODING. The test progam you gave me ran just fine (no core dump). I'm trying to get some directions now on the recommended way to do a full system debug build. When I do, I'll provide more info. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-31 07:43 Message: Logged In: YES user_id=21627 That sounds reasonable, and suggests that the bug is within libiconv. It crashes at the line iconv_t hdl = iconv_open(UNICODE_ENCODING, "ISO-8859-1"); Please do the following steps: a) produce a preprocessor output of _iconv_module.c (with --save-temps), to see what UNICODE_ENCODING expands to. b) write a test program, with #include int main() { iconv_t hdl = iconv_open(UNICODE_ENCODING, "ISO-8859-1"); } and see whether this runs correctly. If it doesn't, it's an OpenBSD bug, if it does, we would need debug information for libiconv as well. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-03-31 06:10 Message: Logged In: YES user_id=699438 Here's a (hopefully) non-bogus traceback. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 23:27 Message: Logged In: YES user_id=21627 The traceback is bogus. For example, in stackframe 19, decode_str does not feature a call to PyUnicodeUCS2_Decode. The most likely reason is that not all object files were built with -g, so that some symbols are missing. I recommend that you rebuild from scratch with --with-pydebug. Make sure you have no object files left over from an earlier build. If this causes the bug to disappear, configure with regular options, and add -g to Makefile.pre manually. In either case, verify that -g does get added to the compile commands. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-03-30 23:05 Message: Logged In: YES user_id=699438 Okay, I lied. I'm primarily a windows developer who's a bit new to the wonderful world of gdb! It found the codec fine. libiconv was just the last library that gdb imported a symbol table from. The error actaully occurs on a realloc() to a list object. I've attached the stack trace if it means anything. man realloc also explains the error message: ``modified (chunk-/page-) pointer.'' The pointer passed to free or realloc has been modified. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-30 11:05 Message: Logged In: YES user_id=21627 It is surprising that it runs into iconv, as test_pep263 should use encodings.koi8_r.Codec, not the IconvCodec. What do you get if you do codecs.lookup("koi8-r") In any case, the iconv codec (when used) should not crash. It looks like there is some memory corruption going on. However, without an OpenBSD system to debug libiconv, this probably won't be found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470 From noreply@sourceforge.net Sun May 4 13:55:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:55:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-704919 ] Problems building python with tkinter on HPUX... Message-ID: Bugs item #704919, was opened at 2003-03-17 12:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jayce Piel (jayce) Assigned to: Nobody/Anonymous (nobody) Summary: Problems building python with tkinter on HPUX... Initial Comment: I have some problems when trying to install python on a HPUX 10.20 system. All seems to go well during the compiling and during the installation process, but when I try to use tkinter in my new python with an "import _tkinter", i have the following lines : Python 2.2.2 (#2, Mar 17 2003, 04:36:02) [GCC 2.95.2 19991024 (release)] on hp-ux10 Type "help", "copyright", "credits" or "license" for more information. >>> import _tkinter /usr/lib/dld.sl: Unresolved symbol: acos (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: asin (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: atan (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: cosh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: log10 (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: sinh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: tan (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: tanh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclTraceExec (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclProcBodyType (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclFreeObjList (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclExecutableName (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: Tcl_FindExecutable (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl zsh: abort (core dumped) python I have a python1.5/tkinter that works with tcl/tk 8.0p2... When trying to compile with this version of tcl/tk, i had errors with the tkinter module compilation. Then, I tried to compile a tcl/tk 8.4.2, or even use a binary-package of a tcl/tk 8.2.1, but in both cases I have the above errors when running... ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:55 Message: Logged In: YES user_id=21627 Closing it as "won't fix"; the submitter apparently is happy with the suggested work-around. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-21 19:06 Message: Logged In: YES user_id=21627 This modification cannot go into the CVS: Hard-coding the path for egcs is not acceptable. Are you interested in developing a proper patch, or are you satisfied with the solution that works for you? ---------------------------------------------------------------------- Comment By: Jayce Piel (jayce) Date: 2003-03-21 15:51 Message: Logged In: YES user_id=5496 OK, all works now... Here are what I need to modify : In the Makefile of tcl 8.4.2 and in the Makefile of tk 8.4.2 : SHLIB_LD = gcc -shared -fPIC LD_SEARCH_FLAGS = In the Makefile of Python : LDSHARED= ld -b -L/usr/lib -lm -L/usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91 .60 -lgcc BLDSHARED= ld -b -L/usr/lib -lm -L/usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91 .60 -lgcc ---------------------------------------------------------------------- Comment By: Jayce Piel (jayce) Date: 2003-03-21 14:37 Message: Logged In: YES user_id=5496 After different tries, I found that adding "-L/usr/lib -lm" as parameters of "ld -b" solved THIS problem... But I still have a problem... Now, when laucnhing Tkinter._test(), I have the error message : "/usr/lib/dld.sl: Unresolved symbol: __udivdi3 (code) from /usr/local/lib/libtcl8.4.sl" And a core dumped... I have compiled tcl/tk without threads, and python without threads too... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-19 01:48 Message: Logged In: YES user_id=33168 The problem appears to be that -lm (ie the math library) needs to be linked, but is not. I do not have access to a 10.20 machine. It also looks like the tcl library may not be found. Perhaps there's a library search problem? Jayce, if you could produce a patch that works for you, I can check in a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470 From noreply@sourceforge.net Sun May 4 13:56:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 05:56:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-703779 ] strange warnings messages in interpreter Message-ID: Bugs item #703779, was opened at 2003-03-14 19:52 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703779&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) >Assigned to: Martin v. Löwis (loewis) Summary: strange warnings messages in interpreter Initial Comment: If the PYTHONSTARTUP environment variable is used, warnings will look strange. The warnings module uses __file__ to try to find the line causing the warning and print it out. __file__ is never reset after being set when processing the startup file. The attached patch fixes this by changing PyRun_SimpleFileExFlags to unset __file__ in the __main__ module dictionary entry after running a file, when it had been set by the routine in the first place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703779&group_id=5470 From noreply@sourceforge.net Sun May 4 14:19:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 06:19:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball Message-ID: Bugs item #728051, was opened at 2003-04-26 14:23 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: Test failures on Linux, Python 2.3b1 tarball Initial Comment: "make test" resulted in: test test_tempfile failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test test_time failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/Python-2.3b1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2003-05-04 13:19 Message: Logged In: YES user_id=56214 It's an ISP-supplied variant of RedHat 6.2. I see 'libc-2.1.3.so' in the /lib directory, so I assume that's the version. Running 'strings' on it, I find: GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Python identifies itself as: Python 2.3b1 (#1, Apr 26 2003, 10:02:40) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 I just tested 2.3a1 andr 2.3a2 to confirm where the errors began. 2.3a1 doesn't show either error. 2.3a2 has the tempfile problem, but not the time problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:42 Message: Logged In: YES user_id=21627 What operating system distribution specifically did you use? What C library does this system use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 From noreply@sourceforge.net Sun May 4 16:00:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 08:00:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball Message-ID: Bugs item #728051, was opened at 2003-04-26 16:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) >Assigned to: Neal Norwitz (nnorwitz) Summary: Test failures on Linux, Python 2.3b1 tarball Initial Comment: "make test" resulted in: test test_tempfile failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test test_time failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/Python-2.3b1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 17:00 Message: Logged In: YES user_id=21627 Neal, it appears you have checked in the test for the AEST zone. Can you analyse the test_time failure in more detail? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-04 15:19 Message: Logged In: YES user_id=56214 It's an ISP-supplied variant of RedHat 6.2. I see 'libc-2.1.3.so' in the /lib directory, so I assume that's the version. Running 'strings' on it, I find: GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Python identifies itself as: Python 2.3b1 (#1, Apr 26 2003, 10:02:40) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 I just tested 2.3a1 andr 2.3a2 to confirm where the errors began. 2.3a1 doesn't show either error. 2.3a2 has the tempfile problem, but not the time problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:42 Message: Logged In: YES user_id=21627 What operating system distribution specifically did you use? What C library does this system use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 From noreply@sourceforge.net Sun May 4 18:49:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 10:49:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-437472 ] MacPy21: sre "recursion limit" bug Message-ID: Bugs item #437472, was opened at 2001-06-29 21:50 Message generated for change (Comment added) made by herron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 Category: Regular Expressions Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: MacPy21: sre "recursion limit" bug Initial Comment: As of Python 2.0, the sre module had bug wherein a "RuntimeError: maximum recursion limit exceeded" would be raised whenever an expression matched something on the order of 16,000+ characters. The bug, nominally fixed in time for Python 2.1, is still present in MacPython 2.1, as evidenced by the following transcript copied from an interactive session with the interpreter. Note success with pre module, however. It makes me curious, since the bug appears to be fixed in WinPython 2.1, whether the correct source was used when compiling MacPython 2.1.... ========== Python 2.1 (#92, Apr 24 2001, 23:59:23) [CW PPC GUSI2 THREADS] on mac >>> import sre, pre, string >>> l = ["XXX", "%"*20000, "XXX"] >>> sre_regex = sre.compile(r"XXX.*?XXX") >>> match_object = sre_regex.search(string.join(l)) Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ### Above error first reported upon release of sre with Python 2.0 ### >>> ### Bug supposedly fixed in Python 2.0.1 release (no Mac version, I know) ### >>> pre_regex = pre.compile(r"XXX.*XXX") >>> match_object = pre_regex.search(string.join(l)) >>> match_object >>> ### Note above success with pre module instead of sre ### >>> ### Wrong sre module source used when compiling MacPython 2.1? ### ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-05-04 17:49 Message: Logged In: YES user_id=395736 This was not a bug, but rather a limitation of the sre engine. That limitation has now been removed (for simple used of "*?" as seen here) in Python 2.3beta1. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-07-02 08:58 Message: Logged In: YES user_id=45365 When I try this in a MacPython build from the CVS repository the sre example does not crash, but match_object ends up as None. Also not the behaviour I expect... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 From noreply@sourceforge.net Sun May 4 20:23:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 12:23:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-732299 ] Doctest chokes on '\x00' Message-ID: Bugs item #732299, was opened at 2003-05-04 15: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=732299&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francis Avila (francisga) Assigned to: Nobody/Anonymous (nobody) Summary: Doctest chokes on '\x00' Initial Comment: $ cat ./dtbug.py """Demonstrate a python doctest bug.""" def main(): """See here, I can't include any string literals with nulls in them: >>> x = '\x00' >>> """ pass if __name__ == '__main__': import doctest, dtbug doctest.testmod(dtbug) $ python ./dtbug.py ******************************************************* ********** Failure in example: x = '' from line #2 of dtbug.main Exception raised: Traceback (most recent call last): File "/usr/lib/python2.2/doctest.py", line 499, in _run_examples_inner exec compile(source, "", "single") in globs TypeError: compile() argument 1 must be string without null bytes, not string ******************************************************* ********** 1 items had failures: 1 of 1 in dtbug.main ***Test Failed*** 1 failures. I'm not actually certain this is really a bug, but it certainly makes it impossible to demonstrate the use of functions that operate on binary data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732299&group_id=5470 From noreply@sourceforge.net Mon May 5 00:21:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 16:21:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-714733 ] cPickle fails to pickle inf Message-ID: Bugs item #714733, was opened at 2003-04-03 16:44 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=714733&group_id=5470 Category: Python Library >Group: Feature Request >Status: Closed >Resolution: Later Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle fails to pickle inf Initial Comment: cPickle fails, and throws an exception when you ask it to pickle infinity, and cPickle is set for binary mode. See example: gpk* python2.2 Python 2.2.1 (#1, Jul 29 2002, 23:15:49) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = float("Inf") >>> x inf >>> import cPickle >>> import sys >>> cPickle.dump(x, sys.stdout) Finf .>>> cPickle.dump(x, sys.stdout, 1) Traceback (most recent call last): File "", line 1, in ? SystemError: frexp() result out of range >>> ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-04 23:21 Message: Logged In: YES user_id=31392 Already listed in PEP 42. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-07 21:09 Message: Logged In: YES user_id=31435 It's true that pickle doesn't know what to do with an infinity. Ditto the struct module. It also doesn't know what to do with a NaN, and doesn't preserve the sign of -0.0. This has always been so; Python doesn't know anything about 754's special values. Note that it's a platform-dependent accident that float("inf") didn't raise an exception. What the platform frexp() does when passed an infinity is also left undefined by C89. In short, Python has no 754 story: anything that works, or doesn't work, wrt infinities, NaNs, and signed zeroes is an accident. About once a year, someone says they're going to volunteer work to improve this. So far, it hasn't happened. Until it does, you're simply out of luck. This should probably be changed to a feature request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=714733&group_id=5470 From noreply@sourceforge.net Mon May 5 00:45:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 16:45:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-723831 ] urlopen(url_to_a_non-existing-domain) raises gaierror Message-ID: Bugs item #723831, was opened at 2003-04-18 18:52 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723831&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Joachim Werner (bavarian) >Assigned to: Jeremy Hylton (jhylton) Summary: urlopen(url_to_a_non-existing-domain) raises gaierror Initial Comment: In Python 2.1.3 trying to open a URL that does point to a non-existing domain with urlopen from urllib2 will raise a urllib2.URLError: That's what I'd expect Python 2.2.2 to do, too. But with Python 2.2.2 I get a socket.gaierror: (-2, 'Name or service not known') Error instead. I think this is a bug because a) one would not expect urlopen to raise errors other than HTTPError and URLError (from what the docs say) b) it breaks code that relies on the error behaviour of Python 2.1.3 Cheers Joachim ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-04 23:45 Message: Logged In: YES user_id=31392 Fixed in rev 1.40. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723831&group_id=5470 From noreply@sourceforge.net Mon May 5 00:52:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 16:52:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-731116 ] urllib2 raises AttributeError on redirect Message-ID: Bugs item #731116, was opened at 2003-05-01 21:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 raises AttributeError on redirect Initial Comment: The code import urllib2 f = urllib2.urlopen('http://www.cwi.nl/~jack/pimp/pimp-darwin-6.5- Power_Macintosh.plist') which is executed by pimp.py when the Macintosh PackageManager is initially brought up, raises an AttributeError when it gets redirected to homepages.cwi.nl. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-04 18:52 Message: Logged In: YES user_id=80475 Jeremy, does your latest check-in take care of this one? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 17:32 Message: Logged In: YES user_id=45365 And I attached the stack trace. ---------------------------------------------------------------------- Comment By: David Lewis (davidmlewis) Date: 2003-05-02 15:17 Message: Logged In: YES user_id=626943 I filed a patch under number 731153, if you want to review it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-02 14:09 Message: Logged In: YES user_id=80475 Please post the whole traceback. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 07:02 Message: Logged In: YES user_id=45365 The problem is a last-minute checkin before 2.3b1, rev 1.39. It refers to a method() method on requests which doesn't exist. Assigning to Raymond, as he did the checkin so he's the easiest scapegoat:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 From noreply@sourceforge.net Mon May 5 01:27:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 17:27:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 12:04 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open >Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-04 20:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-26 21:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-26 21:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-26 21:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 13:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 04:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 11:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 11:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 16:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 16:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 16:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 15:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 16:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 11:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 11:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-09 21:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 17:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 14:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 12:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 13:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 15:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 20:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 17:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 11:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 14:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 12:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-28 20:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 12:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Mon May 5 04:00:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 20:00:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-731116 ] urllib2 raises AttributeError on redirect Message-ID: Bugs item #731116, was opened at 2003-05-02 02:48 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 raises AttributeError on redirect Initial Comment: The code import urllib2 f = urllib2.urlopen('http://www.cwi.nl/~jack/pimp/pimp-darwin-6.5- Power_Macintosh.plist') which is executed by pimp.py when the Macintosh PackageManager is initially brought up, raises an AttributeError when it gets redirected to homepages.cwi.nl. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-05 03:00 Message: Logged In: YES user_id=31392 Fixed in rev. 1.40. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-04 23:52 Message: Logged In: YES user_id=80475 Jeremy, does your latest check-in take care of this one? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 22:32 Message: Logged In: YES user_id=45365 And I attached the stack trace. ---------------------------------------------------------------------- Comment By: David Lewis (davidmlewis) Date: 2003-05-02 20:17 Message: Logged In: YES user_id=626943 I filed a patch under number 731153, if you want to review it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-02 19:09 Message: Logged In: YES user_id=80475 Please post the whole traceback. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-02 12:02 Message: Logged In: YES user_id=45365 The problem is a last-minute checkin before 2.3b1, rev 1.39. It refers to a method() method on requests which doesn't exist. Assigning to Raymond, as he did the checkin so he's the easiest scapegoat:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731116&group_id=5470 From noreply@sourceforge.net Mon May 5 04:07:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 20:07:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-732299 ] Doctest chokes on '\x00' Message-ID: Bugs item #732299, was opened at 2003-05-04 15:23 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732299&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Francis Avila (francisga) >Assigned to: Tim Peters (tim_one) Summary: Doctest chokes on '\x00' Initial Comment: $ cat ./dtbug.py """Demonstrate a python doctest bug.""" def main(): """See here, I can't include any string literals with nulls in them: >>> x = '\x00' >>> """ pass if __name__ == '__main__': import doctest, dtbug doctest.testmod(dtbug) $ python ./dtbug.py ******************************************************* ********** Failure in example: x = '' from line #2 of dtbug.main Exception raised: Traceback (most recent call last): File "/usr/lib/python2.2/doctest.py", line 499, in _run_examples_inner exec compile(source, "", "single") in globs TypeError: compile() argument 1 must be string without null bytes, not string ******************************************************* ********** 1 items had failures: 1 of 1 in dtbug.main ***Test Failed*** 1 failures. I'm not actually certain this is really a bug, but it certainly makes it impossible to demonstrate the use of functions that operate on binary data. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-04 23:07 Message: Logged In: YES user_id=31435 This isn't a bug, can't be helped, but can be avoided. You have to be aware that the doctest goes through *two* stages of string processing: the Python interpreter does one when it's reading your source code. At that time, the \x00 in your doctest string gets changed into a NUL byte. Similarly, all other backslash escape sequences are also processed. The *result* of that is the *input* string doctest sees, and doctest has to pass its input on to the compiler again, in order to run your tests. The easiest way to avoid the problem is to make the docstring a raw string (stick the letter 'r' -- without the quotes -- at the front of the docstring). Another way is to double-up your backslashes, as the docs point out. When Python sees "\x00" it produces a four-character string, a single backslash followed by "x00". That's the one you want doctest to pass on to the compiler. The raw string r"\x00" gets to the same end via a different mechanism. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732299&group_id=5470 From noreply@sourceforge.net Mon May 5 04:49:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 20:49:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-732299 ] Doctest chokes on '\x00' Message-ID: Bugs item #732299, was opened at 2003-05-04 15:23 Message generated for change (Comment added) made by francisga You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732299&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Francis Avila (francisga) Assigned to: Tim Peters (tim_one) Summary: Doctest chokes on '\x00' Initial Comment: $ cat ./dtbug.py """Demonstrate a python doctest bug.""" def main(): """See here, I can't include any string literals with nulls in them: >>> x = '\x00' >>> """ pass if __name__ == '__main__': import doctest, dtbug doctest.testmod(dtbug) $ python ./dtbug.py ******************************************************* ********** Failure in example: x = '' from line #2 of dtbug.main Exception raised: Traceback (most recent call last): File "/usr/lib/python2.2/doctest.py", line 499, in _run_examples_inner exec compile(source, "", "single") in globs TypeError: compile() argument 1 must be string without null bytes, not string ******************************************************* ********** 1 items had failures: 1 of 1 in dtbug.main ***Test Failed*** 1 failures. I'm not actually certain this is really a bug, but it certainly makes it impossible to demonstrate the use of functions that operate on binary data. ---------------------------------------------------------------------- >Comment By: Francis Avila (francisga) Date: 2003-05-04 23:49 Message: Logged In: YES user_id=771433 The docs mention a few "gotcha"s, one of which is that using explicit line continuations must be escaped. I nodded, but I don't think I understood the ramifications. But perhaps the docs should explicitly mention the case of string literals intended to represent binary data? Because it's not simply a case of adding another level of escapes, but that a null is not allowed in a string passed to compile. For example, this works fine: >>> x = '\x01' >>> (This is why I was confused, because in my docstring I had other examples which used *non-null* binary data passed to functions, and these examples passed doctest.) Another workaround, which doesn't involve making docstring text not match interpreter text, is to use chr(0): >>> x = chr(0) >>> This will only be useful in very specific cases, though, like this artificial example. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-04 23:07 Message: Logged In: YES user_id=31435 This isn't a bug, can't be helped, but can be avoided. You have to be aware that the doctest goes through *two* stages of string processing: the Python interpreter does one when it's reading your source code. At that time, the \x00 in your doctest string gets changed into a NUL byte. Similarly, all other backslash escape sequences are also processed. The *result* of that is the *input* string doctest sees, and doctest has to pass its input on to the compiler again, in order to run your tests. The easiest way to avoid the problem is to make the docstring a raw string (stick the letter 'r' -- without the quotes -- at the front of the docstring). Another way is to double-up your backslashes, as the docs point out. When Python sees "\x00" it produces a four-character string, a single backslash followed by "x00". That's the one you want doctest to pass on to the compiler. The raw string r"\x00" gets to the same end via a different mechanism. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732299&group_id=5470 From noreply@sourceforge.net Mon May 5 05:09:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 21:09:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-730963 ] HTTPRedirectHandler variable out of scope Message-ID: Bugs item #730963, was opened at 2003-05-01 19:48 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730963&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Jeremy Hylton (jhylton) Summary: HTTPRedirectHandler variable out of scope Initial Comment: Within class HTTPRedirectHandler(BaseHandler), variable newurl is local to http_error_302, but is used in redirect_request. Since method redirect_request isn't called anywhere else, newurl can just be added to the signature. def redirect_request(self, req, fp, code, msg, headers, newurl): and new = self.redirect_request(req, fp, code, msg, headers, newurl) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-05 04:09 Message: Logged In: YES user_id=31392 Fixed in rev. 1.42 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730963&group_id=5470 From noreply@sourceforge.net Mon May 5 07:12:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 23:12:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-713722 ] Distutils documentation amputated Message-ID: Bugs item #713722, was opened at 2003-04-02 18:27 Message generated for change (Comment added) made by gcewing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713722&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Ewing (gcewing) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils documentation amputated Initial Comment: Somewhere between the 2.0 and 2.1 documentation releases, a big chunk of the Distributing Python Modules manual seems to have gone missing. Section 7 (Examples), 8 (Extending the Distutils) and most of 9 (Reference) are absent. Section 7 contains a small part of what used to be section 9. ---------------------------------------------------------------------- >Comment By: Gregory Ewing (gcewing) Date: 2003-05-05 18:12 Message: Logged In: YES user_id=747684 You're right! I never thought to look any further than the contents page. I guess there's not much that can be done, then. But perhaps at least there should be an "Extending the Distutils" heading which says "Not written yet" or some such, because other parts of the docs make explicit reference to this section! ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-04 09:57 Message: Logged In: YES user_id=31392 Can you be specific about what text was lost? That is, what revision of dist.tex contains the text that is missing? If I look at the 2.0 release documentation, I see an empty section named "Extending the distutils." I don't think there was ever any text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713722&group_id=5470 From noreply@sourceforge.net Mon May 5 07:46:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 23:46:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-437472 ] MacPy21: sre "recursion limit" bug Message-ID: Bugs item #437472, was opened at 2001-06-29 21:50 Message generated for change (Comment added) made by herron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 Category: Regular Expressions Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: MacPy21: sre "recursion limit" bug Initial Comment: As of Python 2.0, the sre module had bug wherein a "RuntimeError: maximum recursion limit exceeded" would be raised whenever an expression matched something on the order of 16,000+ characters. The bug, nominally fixed in time for Python 2.1, is still present in MacPython 2.1, as evidenced by the following transcript copied from an interactive session with the interpreter. Note success with pre module, however. It makes me curious, since the bug appears to be fixed in WinPython 2.1, whether the correct source was used when compiling MacPython 2.1.... ========== Python 2.1 (#92, Apr 24 2001, 23:59:23) [CW PPC GUSI2 THREADS] on mac >>> import sre, pre, string >>> l = ["XXX", "%"*20000, "XXX"] >>> sre_regex = sre.compile(r"XXX.*?XXX") >>> match_object = sre_regex.search(string.join(l)) Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ### Above error first reported upon release of sre with Python 2.0 ### >>> ### Bug supposedly fixed in Python 2.0.1 release (no Mac version, I know) ### >>> pre_regex = pre.compile(r"XXX.*XXX") >>> match_object = pre_regex.search(string.join(l)) >>> match_object >>> ### Note above success with pre module instead of sre ### >>> ### Wrong sre module source used when compiling MacPython 2.1? ### ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-05-05 06:46 Message: Logged In: YES user_id=395736 This was not a bug, but rather a limitation of the sre engine. That limitation has now been removed (for simple used of "*?" as seen here) in Python 2.3beta1. ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-05-04 17:49 Message: Logged In: YES user_id=395736 This was not a bug, but rather a limitation of the sre engine. That limitation has now been removed (for simple used of "*?" as seen here) in Python 2.3beta1. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-07-02 08:58 Message: Logged In: YES user_id=45365 When I try this in a MacPython build from the CVS repository the sre example does not crash, but match_object ends up as None. Also not the behaviour I expect... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 From noreply@sourceforge.net Mon May 5 15:17:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 07:17:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-727137 ] use bsddb185 if necessary in dbhash Message-ID: Bugs item #727137, was opened at 2003-04-24 14:56 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: use bsddb185 if necessary in dbhash Initial Comment: I've had this patch sitting around for awhile. I think if the new bsddb stuff can't be built and the user enables the bsddb185 module in Modules/Setup that dbhash should also try that module when setting things up. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 09:17 Message: Logged In: YES user_id=44345 closing in favor of bug 731501 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 16:20 Message: Logged In: YES user_id=21627 I agree that people will want to use bsddb185 to open existing files, and we should make this readily available. At the same, we should not provide easy means to create new files. So I suggest to reject this patch: If anything is done about dbhash, it should check, on open, what version of the database library needs to be used to open an existing file. It is indeed the case that the current whichdb implementation is not capable of distinguishing BSDB on-disk format versions. Such version information is available inside the file, and it would be possible to teach whichdb about that. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-03 15:17 Message: Logged In: YES user_id=44345 There are valid reasons why people don't update their db library. The most obvious one that occurs to me is that the system itself stores files with that version of the library which applications need to read (I remember the pwd module had this problem at one time. Probably still does under the correct circumstances.) As for whichdb returning "bsddb185", that can only happen if we are willing to an "open" method to it. Even then, whichdb will probably have to be made more discriminating (distinguishing files readable via db 1.85 ("bsddb185") and files readable by more recent versions ("dbhash"). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 10:18 Message: Logged In: YES user_id=21627 -1. I think users should make an explicit decision to use bsddb 1.85, and should get an error if they use any of the libraries on top of it. The only reasonable exception might be whichdb, which could say 'bsddb185', if it recognizes the file format. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727137&group_id=5470 From noreply@sourceforge.net Mon May 5 15:27:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 07:27:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable Message-ID: Bugs item #731501, was opened at 2003-05-02 12:56 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Vargish (vargish) Assigned to: Skip Montanaro (montanaro) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 09:27 Message: Logged In: YES user_id=44345 I believe the attached patch does what's necessary to get this to work again. It does a few things: * setup.py builds the bsddb185 under the right (restrictive) circumstances. /usr/include/db.h must exist and HASHVERSION must be 2. In this case the bsddb185 module will be built without any extra includes, libraries or #defines, forcing whatever is present in /usr/include/db.h and libc to be used to build the module. * whichdb.py detects the older hash file format and returns "bsddb185". * bsddbmodule.c grows an extra undocumented attribute, "open". The last two changes avoid having to change dbhash.py in complicated ways to distinguish between new and old file versions. The format- detecting mess remains isolated to whichdb.py. Using this setup I was successfully able to open /etc/pwd.db on my system using anydbm.open(), which I was unable to do previously. I can also still open a more recent hash file created with anydbm.open. Finally, new files created with anydbm.open are in the later format. Please give it a try. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 04:02 Message: Logged In: YES user_id=21627 I think this is not a bug. open() has determined that this is a bsddb file, but bsddb is not supported on the system. Or did you mean to suggest that opening the very same file with dbm would be successful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 From noreply@sourceforge.net Mon May 5 16:17:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 08:17:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-626926 ] Build error using make VPATH feature Message-ID: Bugs item #626926, was opened at 2002-10-22 11:36 Message generated for change (Comment added) made by tseaver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Davide Di Blasi (davidedb) Assigned to: Nobody/Anonymous (nobody) Summary: Build error using make VPATH feature Initial Comment: PROBLEM DESCRIPTION ===================== After building successfully Python 2.2.2 from scratch on Solaris 8 using the usual commands (cd ~wrk/Python-2.2.2; ./configure; make), I decided to build it for multiple architectures (SunOS 5.6, 5.7 and 5.8), exploiting the supported VPATH feature of GNU make. Here are the commands I run for Solaris 6: 1. mkdir ~/wrk/Python-2.2.2/binaries/SunOS_5.6 2. cd ~/wrk/Python-2.2.2/binaries/SunOS_5.6 3. ../../configure -prefix=/usr/local/python 4. make Unfortunately the last command failed with the following error:... ranlib libpython2.2.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.2.a -lsocket -lnsl -ldl -lpthread -lthread -lm case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py build;; \ esac running build running build_ext Traceback (most recent call last): File "../../setup.py", line 795, in ? main() File "../../setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "~wrk/Python-2.2.2/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "~wrk/Python-2.2.2/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/python/lib/python2.2/config/Makefile (No such file or directory) make: *** [sharedmods] Error 1 PROBLEM ANALYSIS================== By looking the code inside sysconfig.py module, it is clear that the problem is generated by the first IF clause (starting at line 32), where the python_build variable is set: the path obtained by joining "Lib" to the argv0_path variable does not exist, since no directory named Lib exists in the (current) work directory. In fact the only existing directories are: - Grammar - Modules - Objects - Parser - Python - build WORKAROUND ============= Simply create a link to the Lib directory provided with Python 2.2.2, i.e. in my example: ln -s ../../Lib make make test make install ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2003-05-05 11:17 Message: Logged In: YES user_id=127625 The following patch works for me (derived from davideb's work): --- Tools/Python2/configure.in:1.1.1.2 Fri May 2 08:36:31 2003 +++ Tools/Python2/configure.in Mon May 5 10:56:17 2003 @@ -2116,6 +2116,12 @@ done AC_MSG_RESULT(done) +AC_MSG_CHECKING(for Lib directory) +if test ! -d Lib; then + ln -s $srcdir/Lib +fi +AC_MSG_RESULT(done) + # generate output files AC_OUTPUT(Makefile.pre Modules/Setup.config) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 05:39 Message: Logged In: YES user_id=21627 Eventually, your change has to end up in Makefile, right? So I would suggest you start from there: Have configure generate a Makefile, and modify the Makefile so that it suits your needs. If you then don't know how to proceed, please attach both Makefile (the original and the modified one) to this report, and we'll see how to proceed. Most likely, for your change to show up in Makefile, it would have to appear in Makefile.pre, with likely no changes to configure.in/configure. Makefile.pre, in turn, is generated from Makefile.pre.in, so that your change most likely needs to appear in Makefile.pre.in. ---------------------------------------------------------------------- Comment By: Davide Di Blasi (davidedb) Date: 2002-10-28 05:16 Message: Logged In: YES user_id=633937 I'd like to help, but unfortunately I do not know the autoconf configuration file syntax (i.e. configure.in), where - I guess - the problem has to be solved. Yet, by looking at the provided configure script, I added the following lines (starting at line #7600): --------------------- echo $ac_n "checking for Lib directory""... $ac_c" 1>&6 echo "configure: checking for Lib directory" >&5 if test ! -d Lib; then ln -s $srcdir/Lib fi echo "$ac_t""done" 1>&6 --------------------- This works fine when using the VPATH feature as well as when building directly in the standard source directory. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 13:04 Message: Logged In: YES user_id=21627 Would you like to work on a patch that fixes this problem? The patch should support both the case of in-place building, and VPATH building. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 From noreply@sourceforge.net Mon May 5 16:56:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 08:56:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-732761 ] 2.3 breaks email date parsing Message-ID: Bugs item #732761, was opened at 2003-05-05 15: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=732761&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Berlin (dberlin) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 breaks email date parsing Initial Comment: Parsing dates in emails is broken in 2.3 compared to 2.2.2. Changing parsedate_tz back to what it was in 2.2.2 fixes it. I'm not sure who or why this change was made, but it clearly doesn't handle cases it used to: (oldparseaddr is the 2.3 version with the patch at the bottom applied, which reverts it to what it was in 2.2.2) >>> import _parseaddr >>> _parseaddr.parsedate_tz("3 Mar 2001 02:04:50 -0000") >>> import oldparseaddr >>> oldparseaddr.parsedate_tz("3 Mar 2001 02:04:50 -0000") (2001, 3, 3, 2, 4, 50, 0, 0, 0, 0) >>> The problem is obvious from looking at the new code: The old version would only care if it actually found something it needed to delete. The new version assumes there *must* be a comma in the date if there is no dayname, and if there isn't, returns nothing. I wanted to know if this was a mistake, or done on purpose. If it's a mistake, i'll submit a patch to sourceforge to fix it. Index: _parseaddr.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/email/_parseaddr.py,v retrieving revision 1.5 diff -u -3 -p -r1.5 _parseaddr.py --- _parseaddr.py 17 Mar 2003 18:35:42 -0000 1.5 +++ _parseaddr.py 2 May 2003 15:42:30 -0000 @@ -49,14 +49,9 @@ def parsedate_tz(data): data = data.split() # The FWS after the comma after the day-of-week is optional, so search and # adjust for this. - if data[0].endswith(',') or data[0].lower() in _daynames: + if data[0][-1] in (',', '.') or data[0].lower() in _daynames: # There's a dayname here. Skip it del data[0] - else: - i = data[0].rfind(',') - if i < 0: - return None - data[0] = data[0][i+1:] if len(data) == 3: # RFC 850 date, deprecated stuff = data[0].split('-') if len(stuff) == 3: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732761&group_id=5470 From noreply@sourceforge.net Mon May 5 17:14:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:14:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-622042 ] httplib HEAD request fails - keepalive Message-ID: Bugs item #622042, was opened at 2002-10-11 20:15 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Jeremy Hylton (jhylton) Summary: httplib HEAD request fails - keepalive Initial Comment: httplib fails to handle HEAD requests correctly when the server side honors a keep-alive connection. Per RFC2616, sect. 9.4: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in the response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This means that HEAD requests are likely to return a non-zero Content-Length, but with no body. The attached script, if called against an HTTP/1.1, keep-alive-aware server (try www.microsoft.com or www.redhat.com) will hang instead of finishing, because read() will expect to read some bytes from the connection. The script was tested against version 1.66 of httplib (the current HEAD). HTTP/1.0 and Connection: close (with HTTP/1.1) work as expected because the server closes the connection. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-05 16:14 Message: Logged In: YES user_id=31392 Fixed in rev. 1.75 of httplib.py ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-10-15 16:03 Message: Logged In: YES user_id=205865 Not necessarily the best approach, but it does fix the problem. The library already special-case some return codes that guarantee the body is always zero-length. Signalling that HEAD requests need the same punishment is all it takes. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-10-15 13:44 Message: Logged In: YES user_id=205865 Yes, I will upload the patch as soon as possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 23:57 Message: Logged In: YES user_id=6380 Sure seems that way. ;-( For example this hangs: python2.3 http-request.py python.org while this returns correctly: python2.3 http-request.py zope.com Mihai, do you have a proposed fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 From noreply@sourceforge.net Mon May 5 17:31:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:31:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-732783 ] test_grp failure on Mac OS X Message-ID: Bugs item #732783, was opened at 2003-05-05 11: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=732783&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Walter Dörwald (doerwalter) Summary: test_grp failure on Mac OS X Initial Comment: I noticed that test_grp began failing for me on Mac OS X. I thought perhaps it was related to the changes Martin checked in for grpmodule.c Saturday (May 3rd) for OpenVMS, but a Python executable built on May 2nd also fails to pass the test. However, it passes using 2.2.2 (running against the 2.2.2 version of the test). % ./python.exe ../Lib/test/test_grp.py test_errors (__main__.GroupDatabaseTestCase) ... ok test_values (__main__.GroupDatabaseTestCase) ... FAIL =========================================== =========================== FAIL: test_values (__main__.GroupDatabaseTestCase) ----------------------------------------------------------- ----------- Traceback (most recent call last): File "../Lib/test/test_grp.py", line 46, in test_values self.assert_(max([self.valueseq(e2, x) \ File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError ----------------------------------------------------------- ----------- Ran 2 tests in 0.162s FAILED (failures=1) Traceback (most recent call last): File "../Lib/test/test_grp.py", line 103, in ? test_main() File "../Lib/test/test_grp.py", line 100, in test_main test_support.run_unittest(GroupDatabaseTestCase) File "/Users/skip/src/python/head/dist/src/Lib/test/ test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "/Users/skip/src/python/head/dist/src/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_grp.py", line 46, in test_values self.assert_(max([self.valueseq(e2, x) \ File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError I wonder if it's related to Walter's changes to test_grp.py on or about versions 1.14 or 1.15? Here's a session transcript which shows a couple problems. "ebygid" is a dict like entriesbygid in test_grp.py. "entries" is the output of grp.getgrall(). >>> pprint.pprint(ebygid) {-2: [('nobody', '*', -2, [])], -1: [('nogroup', '*', -1, [])], 0: [('wheel', '*', 0, ['skip'])], 1: [('daemon', '*', 1, ['root'])], 2: [('kmem', '*', 2, ['root'])], 3: [('sys', '*', 3, ['root'])], 4: [('tty', '*', 4, ['root'])], 5: [('operator', '*', 5, ['root'])], 6: [('mail', '*', 6, [])], 7: [('bin', '*', 7, [])], 20: [('staff', '*', 20, ['root'])], 25: [('smmsp', '*', 25, [])], 31: [('guest', '*', 31, ['root'])], 45: [('utmp', '*', 45, [])], 66: [('uucp', '*', 66, [])], 68: [('dialer', '*', 68, [])], 69: [('network', '*', 69, [])], 70: [('www', '*', 70, [])], 75: [('sshd', '*', 75, [])], 80: [('admin', '*', 80, ['root', 'skip'])], 99: [('unknown', '*', 99, [])], 250: [('news', '*', 250, [])], 251: [('mysql', '*', 251, [])], 252: [('pgsql', '*', 252, []), ('postgres', '*', 252, ['skip'])], 253: [('games', '*', 253, [])], 254: [('canna', '*', 254, [])], 255: [('postfix', '*', 255, [])], 256: [('maildrop', '*', 256, [])], 257: [('tomcat', '*', 257, [])], 258: [('jabber', '*', 258, [])], 259: [('opennms', '*', 259, [])], 260: [('clamav', '*', 260, [])]} >>> for e in entries: ... e2 = grp.getgrgid (e.gr_gid) ... print e2 ... print [veq(e2, x) for x in ebygid[e.gr_gid]] ... ('nobody', '', -2, []) [True] ('nogroup', '', -1, []) [True] ('wheel', '', 0, ['skip']) [True] ('daemon', '', 1, ['root']) [True] ('kmem', '', 2, ['root']) [True] ('sys', '', 3, ['root']) [True] ('tty', '', 4, ['root']) [True] ('operator', '', 5, ['root']) [True] ('mail', '', 6, []) [True] ('bin', '', 7, []) [True] ('staff', '', 20, ['root']) [True] ('guest', '', 31, ['root']) [True] ('utmp', '', 45, []) [True] ('uucp', '', 66, []) [True] ('dialer', '', 68, []) [True] ('network', '', 69, []) [True] ('www', '', 70, []) [True] ('admin', '', 80, ['root', 'skip']) [True] ('unknown', '', 99, []) [True] ('smmsp', '', 25, []) [True] ('mysql', '', 251, []) [True] ('sshd', '', 75, []) [True] ('news', '', 250, []) [True] ('pgsql', '', 252, ['skip']) [False, False] ('games', '', 253, []) [True] ('canna', '', 254, []) [True] ('postfix', '', 255, []) [True] ('maildrop', '', 256, []) [True] ('tomcat', '', 257, []) [True] ('jabber', '', 258, []) [True] ('opennms', '', 259, []) [True] ('clamav', '', 260, []) [True] ('pgsql', '', 252, ['skip']) [False, False] I think it arises from the fact that on my machine I have two group entries with the same id but different names (pgsql and postgres). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732783&group_id=5470 From noreply@sourceforge.net Mon May 5 17:33:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:33:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib Message-ID: Bugs item #666219, was opened at 2003-01-11 14:23 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Skip Montanaro (montanaro) Assigned to: Jeremy Hylton (jhylton) Summary: AssertionErrors in httplib Initial Comment: I've recently noticed AssertionErrors being raised by httplib.LineAndFileWrapper.read(). It happens reliably when the server exits unexpectedly. Here's an example of an AssertionError in an xmlrpclib client when I kill the server it's talking to: Traceback (most recent call last): File "qa.py", line 22, in ? x = s.query(tmpl, st, en, radius, age) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__ return self.__send(self.__name, args) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request verbose=self.__verbose File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request return self._parse_response(h.getfile(), sock) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response response = file.read(1024) File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read assert not self._line_consumed and self._line_left AssertionError I don't see a problem with raising an exception in this situation. I just wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code). If an exception is being raised because the server went away, I think it would be better to raise IncompleteRead. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-05 16:33 Message: Logged In: YES user_id=31392 We can provoke this error by setting a very small timeout, right? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-03-20 18:43 Message: Logged In: YES user_id=44345 Sorry for the delay on this. I think I'm closing in on the problem. I've been using Tim O'Malley's timeoutsocket module for quite awhile. I noticed the same problem today when using the new timeout feature in the socket module. Libraries like xmlrpclib use makefile() to get a file object to play with. File objects don't play well with timeouts because the socket is in non-blocking mode. I think what happens here is that the first line of HTTPResponse. _read_status sets line to the empty string because of the timeout setting. Tracing through the code which follows makes it clear that control will wind up in the HTTP/0.9 chunk of code. Maybe it's worth adding a test for line == "" after the readline() call: line = self.fp.readline() if self.debuglevel > 0: print "reply:", repr(line) if line == "": raise BadStatusLine(line) That would distinguish an error reading from an 0.9 server (which would return something with that first readline() call). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 14:13 Message: Logged In: YES user_id=44345 No, sorry, I haven't looked more deeply into the problem. I did investigate far enough to also see that the code was in the HTTP/0.9 weeds and am befuddled about why it would be there. It's using the vanilla xmlrpclib module at both ends. I'll try to spend a little time today. S ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-31 14:07 Message: Logged In: YES user_id=31392 Any more info Skip? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-14 21:18 Message: Logged In: YES user_id=31392 It's definitely the case that an AssertionError shouldn't be raised. It was my intention that the assert never fail. Do you know which part of the assert fails? Perhaps you could change the assert to print the values of _line_consumed and _line_left and run some more tests. I can't figure out how this goes wrong. Also, do you know when the server is sending an HTTP/0.9 response? I wonder if there's a bug somewhere else and the client is guessing the wrong protocol version for the response. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 From noreply@sourceforge.net Mon May 5 17:41:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:41:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-697990 ] Document strptime limitation Message-ID: Bugs item #697990, was opened at 2003-03-05 13:48 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) >Assigned to: Brett Cannon (bcannon) Summary: Document strptime limitation Initial Comment: Python Library Reference, Chapter 6.9: strptime: Many (at least glibc 2) versions of strptime can't parse the time zone (which strftime prints with %Z). This should be mentioned as a warning in the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 From noreply@sourceforge.net Mon May 5 17:44:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:44:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-697983 ] Mention gmtime in Chapter 6.9 "Time access and conversions" Message-ID: Bugs item #697983, was opened at 2003-03-05 13:36 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697983&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erland Lewin (erl) >Assigned to: Neal Norwitz (nnorwitz) Summary: Mention gmtime in Chapter 6.9 "Time access and conversions" Initial Comment: The function gmtime is in the calendar module, but is highly related to the functions in the time module. I therefore suggest that chapter 6.9 "Time access and conversions" mention the existance of the gmtime function. Furthermore I would suggest that the gmtime function would suit better in the time module than the calendar module, but I will make this a separate request for enhancement... ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-05 16:44 Message: Logged In: YES user_id=31392 Duplicate of bug fixed by Neal in rev 1.52 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697983&group_id=5470 From noreply@sourceforge.net Mon May 5 17:46:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:46:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-697988 ] Clarify daylight variable meaning Message-ID: Bugs item #697988, was opened at 2003-03-05 13:46 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697988&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erland Lewin (erl) >Assigned to: Jeremy Hylton (jhylton) Summary: Clarify daylight variable meaning Initial Comment: Python Library Reference: Chapter 6.9 Clarify what the daylight variable means - is it true if daylight savings time is in effect in the local time zone, or is it true if the local time zone has daylight savings time during some part of the year? I think the correct answer is the latter, by comparing with C documentation. This should be documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697988&group_id=5470 From noreply@sourceforge.net Mon May 5 17:46:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:46:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-697989 ] Clarify mktime semantics Message-ID: Bugs item #697989, was opened at 2003-03-05 13:46 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erland Lewin (erl) >Assigned to: Jeremy Hylton (jhylton) Summary: Clarify mktime semantics Initial Comment: Python Library Reference, Chapter 6.9 mktime: I believe the C mktime calls ignore the weekday and Julian day values in the tuple. I therefor assume that the Python function also does so, which should be documented. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-06 19:01 Message: Logged In: YES user_id=31435 Yup, I agree the spec is clear on this specific point. I'd rather the docs refer users to the platform C docs, though, as many other aspects of mktime can and do vary across implementations (for example, C is silent on the origin of the epoch, while POSIX defines it; C and POSIX are both clear as mud about how out-of-range struct tm members are to be treated; etc -- google for mktime man pages to see what a mess this function really is across platforms). ---------------------------------------------------------------------- Comment By: Erland Lewin (erl) Date: 2003-03-06 15:44 Message: Logged In: YES user_id=116933 I have a draft of the C99 standard, which in paragraph 7.23.2.3 describes mktime, and says: "The original values of the tm_wday and tm_yday components of the structure are ignored..." So, I would say that mktime() is *not* underspecified by ISO C. In order to write correct programs, it is neccessary to know the semantics of the functions, and IMHO the manual should specify what can be expected of them. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-05 19:05 Message: Logged In: YES user_id=31435 Python does (for the most part) inherit mktime semantics from the platform C, but mktime() is "underspecified" by ANSI C and there's little that can be said about oddball cases across platforms. Sometimes it even depends on the preprocessor symbols defined when the platform C library was compiled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 From noreply@sourceforge.net Mon May 5 17:46:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:46:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-697986 ] Clarify timegm documentation Message-ID: Bugs item #697986, was opened at 2003-03-05 13:43 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697986&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erland Lewin (erl) >Assigned to: Jeremy Hylton (jhylton) Summary: Clarify timegm documentation Initial Comment: Python Library Reference Chapter 5.13: timegm. I assume that this function, taking a tm tuple as input, ignores the weekday and Julian day values in the tuple, just like mktime does in C. This should be documented. See also bug #697983 and RFE #697985 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697986&group_id=5470 From noreply@sourceforge.net Mon May 5 17:48:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 09:48:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib Message-ID: Bugs item #666219, was opened at 2003-01-11 08:23 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Skip Montanaro (montanaro) Assigned to: Jeremy Hylton (jhylton) Summary: AssertionErrors in httplib Initial Comment: I've recently noticed AssertionErrors being raised by httplib.LineAndFileWrapper.read(). It happens reliably when the server exits unexpectedly. Here's an example of an AssertionError in an xmlrpclib client when I kill the server it's talking to: Traceback (most recent call last): File "qa.py", line 22, in ? x = s.query(tmpl, st, en, radius, age) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__ return self.__send(self.__name, args) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request verbose=self.__verbose File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request return self._parse_response(h.getfile(), sock) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response response = file.read(1024) File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read assert not self._line_consumed and self._line_left AssertionError I don't see a problem with raising an exception in this situation. I just wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code). If an exception is being raised because the server went away, I think it would be better to raise IncompleteRead. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 11:48 Message: Logged In: YES user_id=44345 [small timeout?] Not since the changes to the makefile() changes to socket.py (or at least not always). If the timeout is shorter than the response time you now can get a socket.error: >>> socket.setdefaulttimeout(0.05) >>> manatee = xmlrpclib.ServerProxy("http://manatee.mojam.com:5007") >>> manatee.noop() Traceback (most recent call last): File "", line 1, in ? File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1021, in __call__ return self.__send(self.__name, args) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1308, in __request verbose=self.__verbose File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1056, in request errcode, errmsg, headers = h.getreply() File "/Users/skip/local/lib/python2.3/httplib.py", line 1019, in getreply response = self._conn.getresponse() File "/Users/skip/local/lib/python2.3/httplib.py", line 770, in getresponse response.begin() File "/Users/skip/local/lib/python2.3/httplib.py", line 268, in begin version, status, reason = self._read_status() File "/Users/skip/local/lib/python2.3/httplib.py", line 230, in _read_status line = self.fp.readline() File "/Users/skip/local/lib/python2.3/socket.py", line 321, in readline data = recv(1) socket.error: (35, 'Resource temporarily unavailable') I think you may still get the assertion error if the timeout is sufficient to allow some of the response to be read, but not all of it (though that's just a guess). I suspect we're better off just closing this with either "postponed" or "won't fix" at this point. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-05 11:33 Message: Logged In: YES user_id=31392 We can provoke this error by setting a very small timeout, right? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-03-20 12:43 Message: Logged In: YES user_id=44345 Sorry for the delay on this. I think I'm closing in on the problem. I've been using Tim O'Malley's timeoutsocket module for quite awhile. I noticed the same problem today when using the new timeout feature in the socket module. Libraries like xmlrpclib use makefile() to get a file object to play with. File objects don't play well with timeouts because the socket is in non-blocking mode. I think what happens here is that the first line of HTTPResponse. _read_status sets line to the empty string because of the timeout setting. Tracing through the code which follows makes it clear that control will wind up in the HTTP/0.9 chunk of code. Maybe it's worth adding a test for line == "" after the readline() call: line = self.fp.readline() if self.debuglevel > 0: print "reply:", repr(line) if line == "": raise BadStatusLine(line) That would distinguish an error reading from an 0.9 server (which would return something with that first readline() call). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 08:13 Message: Logged In: YES user_id=44345 No, sorry, I haven't looked more deeply into the problem. I did investigate far enough to also see that the code was in the HTTP/0.9 weeds and am befuddled about why it would be there. It's using the vanilla xmlrpclib module at both ends. I'll try to spend a little time today. S ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-31 08:07 Message: Logged In: YES user_id=31392 Any more info Skip? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-14 15:18 Message: Logged In: YES user_id=31392 It's definitely the case that an AssertionError shouldn't be raised. It was my intention that the assert never fail. Do you know which part of the assert fails? Perhaps you could change the assert to print the values of _line_consumed and _line_left and run some more tests. I can't figure out how this goes wrong. Also, do you know when the server is sending an HTTP/0.9 response? I wonder if there's a bug somewhere else and the client is guessing the wrong protocol version for the response. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 From noreply@sourceforge.net Mon May 5 18:44:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 10:44:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-626926 ] Build error using make VPATH feature Message-ID: Bugs item #626926, was opened at 2002-10-22 11:36 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Davide Di Blasi (davidedb) Assigned to: Nobody/Anonymous (nobody) Summary: Build error using make VPATH feature Initial Comment: PROBLEM DESCRIPTION ===================== After building successfully Python 2.2.2 from scratch on Solaris 8 using the usual commands (cd ~wrk/Python-2.2.2; ./configure; make), I decided to build it for multiple architectures (SunOS 5.6, 5.7 and 5.8), exploiting the supported VPATH feature of GNU make. Here are the commands I run for Solaris 6: 1. mkdir ~/wrk/Python-2.2.2/binaries/SunOS_5.6 2. cd ~/wrk/Python-2.2.2/binaries/SunOS_5.6 3. ../../configure -prefix=/usr/local/python 4. make Unfortunately the last command failed with the following error:... ranlib libpython2.2.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.2.a -lsocket -lnsl -ldl -lpthread -lthread -lm case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py build;; \ esac running build running build_ext Traceback (most recent call last): File "../../setup.py", line 795, in ? main() File "../../setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "~wrk/Python-2.2.2/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "~wrk/Python-2.2.2/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/python/lib/python2.2/config/Makefile (No such file or directory) make: *** [sharedmods] Error 1 PROBLEM ANALYSIS================== By looking the code inside sysconfig.py module, it is clear that the problem is generated by the first IF clause (starting at line 32), where the python_build variable is set: the path obtained by joining "Lib" to the argv0_path variable does not exist, since no directory named Lib exists in the (current) work directory. In fact the only existing directories are: - Grammar - Modules - Objects - Parser - Python - build WORKAROUND ============= Simply create a link to the Lib directory provided with Python 2.2.2, i.e. in my example: ln -s ../../Lib make make test make install ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 13:44 Message: Logged In: YES user_id=6380 Tres's patch may work, but I think creating a symlink in the build directory named "Lib" pointing to the source Lib directory just masks the real problem. What is the real problem? ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2003-05-05 11:17 Message: Logged In: YES user_id=127625 The following patch works for me (derived from davideb's work): --- Tools/Python2/configure.in:1.1.1.2 Fri May 2 08:36:31 2003 +++ Tools/Python2/configure.in Mon May 5 10:56:17 2003 @@ -2116,6 +2116,12 @@ done AC_MSG_RESULT(done) +AC_MSG_CHECKING(for Lib directory) +if test ! -d Lib; then + ln -s $srcdir/Lib +fi +AC_MSG_RESULT(done) + # generate output files AC_OUTPUT(Makefile.pre Modules/Setup.config) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 05:39 Message: Logged In: YES user_id=21627 Eventually, your change has to end up in Makefile, right? So I would suggest you start from there: Have configure generate a Makefile, and modify the Makefile so that it suits your needs. If you then don't know how to proceed, please attach both Makefile (the original and the modified one) to this report, and we'll see how to proceed. Most likely, for your change to show up in Makefile, it would have to appear in Makefile.pre, with likely no changes to configure.in/configure. Makefile.pre, in turn, is generated from Makefile.pre.in, so that your change most likely needs to appear in Makefile.pre.in. ---------------------------------------------------------------------- Comment By: Davide Di Blasi (davidedb) Date: 2002-10-28 05:16 Message: Logged In: YES user_id=633937 I'd like to help, but unfortunately I do not know the autoconf configuration file syntax (i.e. configure.in), where - I guess - the problem has to be solved. Yet, by looking at the provided configure script, I added the following lines (starting at line #7600): --------------------- echo $ac_n "checking for Lib directory""... $ac_c" 1>&6 echo "configure: checking for Lib directory" >&5 if test ! -d Lib; then ln -s $srcdir/Lib fi echo "$ac_t""done" 1>&6 --------------------- This works fine when using the VPATH feature as well as when building directly in the standard source directory. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 13:04 Message: Logged In: YES user_id=21627 Would you like to work on a patch that fixes this problem? The patch should support both the case of in-place building, and VPATH building. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 From noreply@sourceforge.net Mon May 5 18:49:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 10:49:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-626926 ] Build error using make VPATH feature Message-ID: Bugs item #626926, was opened at 2002-10-22 16:36 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Davide Di Blasi (davidedb) Assigned to: Nobody/Anonymous (nobody) Summary: Build error using make VPATH feature Initial Comment: PROBLEM DESCRIPTION ===================== After building successfully Python 2.2.2 from scratch on Solaris 8 using the usual commands (cd ~wrk/Python-2.2.2; ./configure; make), I decided to build it for multiple architectures (SunOS 5.6, 5.7 and 5.8), exploiting the supported VPATH feature of GNU make. Here are the commands I run for Solaris 6: 1. mkdir ~/wrk/Python-2.2.2/binaries/SunOS_5.6 2. cd ~/wrk/Python-2.2.2/binaries/SunOS_5.6 3. ../../configure -prefix=/usr/local/python 4. make Unfortunately the last command failed with the following error:... ranlib libpython2.2.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.2.a -lsocket -lnsl -ldl -lpthread -lthread -lm case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py build;; \ esac running build running build_ext Traceback (most recent call last): File "../../setup.py", line 795, in ? main() File "../../setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "~wrk/Python-2.2.2/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "~wrk/Python-2.2.2/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/python/lib/python2.2/config/Makefile (No such file or directory) make: *** [sharedmods] Error 1 PROBLEM ANALYSIS================== By looking the code inside sysconfig.py module, it is clear that the problem is generated by the first IF clause (starting at line 32), where the python_build variable is set: the path obtained by joining "Lib" to the argv0_path variable does not exist, since no directory named Lib exists in the (current) work directory. In fact the only existing directories are: - Grammar - Modules - Objects - Parser - Python - build WORKAROUND ============= Simply create a link to the Lib directory provided with Python 2.2.2, i.e. in my example: ln -s ../../Lib make make test make install ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-05-05 18:49 Message: Logged In: YES user_id=6656 I think I may have fixed this in CVS some time ago... (on the release22-maint branch). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=6380 Tres's patch may work, but I think creating a symlink in the build directory named "Lib" pointing to the source Lib directory just masks the real problem. What is the real problem? ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2003-05-05 16:17 Message: Logged In: YES user_id=127625 The following patch works for me (derived from davideb's work): --- Tools/Python2/configure.in:1.1.1.2 Fri May 2 08:36:31 2003 +++ Tools/Python2/configure.in Mon May 5 10:56:17 2003 @@ -2116,6 +2116,12 @@ done AC_MSG_RESULT(done) +AC_MSG_CHECKING(for Lib directory) +if test ! -d Lib; then + ln -s $srcdir/Lib +fi +AC_MSG_RESULT(done) + # generate output files AC_OUTPUT(Makefile.pre Modules/Setup.config) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 10:39 Message: Logged In: YES user_id=21627 Eventually, your change has to end up in Makefile, right? So I would suggest you start from there: Have configure generate a Makefile, and modify the Makefile so that it suits your needs. If you then don't know how to proceed, please attach both Makefile (the original and the modified one) to this report, and we'll see how to proceed. Most likely, for your change to show up in Makefile, it would have to appear in Makefile.pre, with likely no changes to configure.in/configure. Makefile.pre, in turn, is generated from Makefile.pre.in, so that your change most likely needs to appear in Makefile.pre.in. ---------------------------------------------------------------------- Comment By: Davide Di Blasi (davidedb) Date: 2002-10-28 10:16 Message: Logged In: YES user_id=633937 I'd like to help, but unfortunately I do not know the autoconf configuration file syntax (i.e. configure.in), where - I guess - the problem has to be solved. Yet, by looking at the provided configure script, I added the following lines (starting at line #7600): --------------------- echo $ac_n "checking for Lib directory""... $ac_c" 1>&6 echo "configure: checking for Lib directory" >&5 if test ! -d Lib; then ln -s $srcdir/Lib fi echo "$ac_t""done" 1>&6 --------------------- This works fine when using the VPATH feature as well as when building directly in the standard source directory. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 18:04 Message: Logged In: YES user_id=21627 Would you like to work on a patch that fixes this problem? The patch should support both the case of in-place building, and VPATH building. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 From noreply@sourceforge.net Mon May 5 18:52:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 10:52:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-626926 ] Build error using make VPATH feature Message-ID: Bugs item #626926, was opened at 2002-10-22 11:36 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Davide Di Blasi (davidedb) Assigned to: Nobody/Anonymous (nobody) Summary: Build error using make VPATH feature Initial Comment: PROBLEM DESCRIPTION ===================== After building successfully Python 2.2.2 from scratch on Solaris 8 using the usual commands (cd ~wrk/Python-2.2.2; ./configure; make), I decided to build it for multiple architectures (SunOS 5.6, 5.7 and 5.8), exploiting the supported VPATH feature of GNU make. Here are the commands I run for Solaris 6: 1. mkdir ~/wrk/Python-2.2.2/binaries/SunOS_5.6 2. cd ~/wrk/Python-2.2.2/binaries/SunOS_5.6 3. ../../configure -prefix=/usr/local/python 4. make Unfortunately the last command failed with the following error:... ranlib libpython2.2.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.2.a -lsocket -lnsl -ldl -lpthread -lthread -lm case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py build;; \ esac running build running build_ext Traceback (most recent call last): File "../../setup.py", line 795, in ? main() File "../../setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "~wrk/Python-2.2.2/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "~wrk/Python-2.2.2/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/python/lib/python2.2/config/Makefile (No such file or directory) make: *** [sharedmods] Error 1 PROBLEM ANALYSIS================== By looking the code inside sysconfig.py module, it is clear that the problem is generated by the first IF clause (starting at line 32), where the python_build variable is set: the path obtained by joining "Lib" to the argv0_path variable does not exist, since no directory named Lib exists in the (current) work directory. In fact the only existing directories are: - Grammar - Modules - Objects - Parser - Python - build WORKAROUND ============= Simply create a link to the Lib directory provided with Python 2.2.2, i.e. in my example: ln -s ../../Lib make make test make install ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 13:52 Message: Logged In: YES user_id=6380 Could you find details about the fix? I still get failures when I build Python outside the src directory when there's no Python installation in /usr/local/. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-05 13:49 Message: Logged In: YES user_id=6656 I think I may have fixed this in CVS some time ago... (on the release22-maint branch). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 13:44 Message: Logged In: YES user_id=6380 Tres's patch may work, but I think creating a symlink in the build directory named "Lib" pointing to the source Lib directory just masks the real problem. What is the real problem? ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2003-05-05 11:17 Message: Logged In: YES user_id=127625 The following patch works for me (derived from davideb's work): --- Tools/Python2/configure.in:1.1.1.2 Fri May 2 08:36:31 2003 +++ Tools/Python2/configure.in Mon May 5 10:56:17 2003 @@ -2116,6 +2116,12 @@ done AC_MSG_RESULT(done) +AC_MSG_CHECKING(for Lib directory) +if test ! -d Lib; then + ln -s $srcdir/Lib +fi +AC_MSG_RESULT(done) + # generate output files AC_OUTPUT(Makefile.pre Modules/Setup.config) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 05:39 Message: Logged In: YES user_id=21627 Eventually, your change has to end up in Makefile, right? So I would suggest you start from there: Have configure generate a Makefile, and modify the Makefile so that it suits your needs. If you then don't know how to proceed, please attach both Makefile (the original and the modified one) to this report, and we'll see how to proceed. Most likely, for your change to show up in Makefile, it would have to appear in Makefile.pre, with likely no changes to configure.in/configure. Makefile.pre, in turn, is generated from Makefile.pre.in, so that your change most likely needs to appear in Makefile.pre.in. ---------------------------------------------------------------------- Comment By: Davide Di Blasi (davidedb) Date: 2002-10-28 05:16 Message: Logged In: YES user_id=633937 I'd like to help, but unfortunately I do not know the autoconf configuration file syntax (i.e. configure.in), where - I guess - the problem has to be solved. Yet, by looking at the provided configure script, I added the following lines (starting at line #7600): --------------------- echo $ac_n "checking for Lib directory""... $ac_c" 1>&6 echo "configure: checking for Lib directory" >&5 if test ! -d Lib; then ln -s $srcdir/Lib fi echo "$ac_t""done" 1>&6 --------------------- This works fine when using the VPATH feature as well as when building directly in the standard source directory. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 13:04 Message: Logged In: YES user_id=21627 Would you like to work on a patch that fixes this problem? The patch should support both the case of in-place building, and VPATH building. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 From noreply@sourceforge.net Mon May 5 19:12:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 11:12:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-626926 ] Build error using make VPATH feature Message-ID: Bugs item #626926, was opened at 2002-10-22 16:36 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Davide Di Blasi (davidedb) Assigned to: Nobody/Anonymous (nobody) Summary: Build error using make VPATH feature Initial Comment: PROBLEM DESCRIPTION ===================== After building successfully Python 2.2.2 from scratch on Solaris 8 using the usual commands (cd ~wrk/Python-2.2.2; ./configure; make), I decided to build it for multiple architectures (SunOS 5.6, 5.7 and 5.8), exploiting the supported VPATH feature of GNU make. Here are the commands I run for Solaris 6: 1. mkdir ~/wrk/Python-2.2.2/binaries/SunOS_5.6 2. cd ~/wrk/Python-2.2.2/binaries/SunOS_5.6 3. ../../configure -prefix=/usr/local/python 4. make Unfortunately the last command failed with the following error:... ranlib libpython2.2.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.2.a -lsocket -lnsl -ldl -lpthread -lthread -lm case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py build;; \ esac running build running build_ext Traceback (most recent call last): File "../../setup.py", line 795, in ? main() File "../../setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "~wrk/Python-2.2.2/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "~wrk/Python-2.2.2/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/python/lib/python2.2/config/Makefile (No such file or directory) make: *** [sharedmods] Error 1 PROBLEM ANALYSIS================== By looking the code inside sysconfig.py module, it is clear that the problem is generated by the first IF clause (starting at line 32), where the python_build variable is set: the path obtained by joining "Lib" to the argv0_path variable does not exist, since no directory named Lib exists in the (current) work directory. In fact the only existing directories are: - Grammar - Modules - Objects - Parser - Python - build WORKAROUND ============= Simply create a link to the Lib directory provided with Python 2.2.2, i.e. in my example: ln -s ../../Lib make make test make install ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-05-05 19:12 Message: Logged In: YES user_id=6656 Well, it works for me. I can't tell you what revision of sysconfig.py I made my fix in, because CVS has just stopped working :-( It was shortly after 222 went out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 18:52 Message: Logged In: YES user_id=6380 Could you find details about the fix? I still get failures when I build Python outside the src directory when there's no Python installation in /usr/local/. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-05 18:49 Message: Logged In: YES user_id=6656 I think I may have fixed this in CVS some time ago... (on the release22-maint branch). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=6380 Tres's patch may work, but I think creating a symlink in the build directory named "Lib" pointing to the source Lib directory just masks the real problem. What is the real problem? ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2003-05-05 16:17 Message: Logged In: YES user_id=127625 The following patch works for me (derived from davideb's work): --- Tools/Python2/configure.in:1.1.1.2 Fri May 2 08:36:31 2003 +++ Tools/Python2/configure.in Mon May 5 10:56:17 2003 @@ -2116,6 +2116,12 @@ done AC_MSG_RESULT(done) +AC_MSG_CHECKING(for Lib directory) +if test ! -d Lib; then + ln -s $srcdir/Lib +fi +AC_MSG_RESULT(done) + # generate output files AC_OUTPUT(Makefile.pre Modules/Setup.config) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 10:39 Message: Logged In: YES user_id=21627 Eventually, your change has to end up in Makefile, right? So I would suggest you start from there: Have configure generate a Makefile, and modify the Makefile so that it suits your needs. If you then don't know how to proceed, please attach both Makefile (the original and the modified one) to this report, and we'll see how to proceed. Most likely, for your change to show up in Makefile, it would have to appear in Makefile.pre, with likely no changes to configure.in/configure. Makefile.pre, in turn, is generated from Makefile.pre.in, so that your change most likely needs to appear in Makefile.pre.in. ---------------------------------------------------------------------- Comment By: Davide Di Blasi (davidedb) Date: 2002-10-28 10:16 Message: Logged In: YES user_id=633937 I'd like to help, but unfortunately I do not know the autoconf configuration file syntax (i.e. configure.in), where - I guess - the problem has to be solved. Yet, by looking at the provided configure script, I added the following lines (starting at line #7600): --------------------- echo $ac_n "checking for Lib directory""... $ac_c" 1>&6 echo "configure: checking for Lib directory" >&5 if test ! -d Lib; then ln -s $srcdir/Lib fi echo "$ac_t""done" 1>&6 --------------------- This works fine when using the VPATH feature as well as when building directly in the standard source directory. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 18:04 Message: Logged In: YES user_id=21627 Would you like to work on a patch that fixes this problem? The patch should support both the case of in-place building, and VPATH building. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 From noreply@sourceforge.net Mon May 5 19:44:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 11:44:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Mon May 5 20:47:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 12:47:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-732783 ] test_grp failure on Mac OS X Message-ID: Bugs item #732783, was opened at 2003-05-05 18:31 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732783&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Walter Dörwald (doerwalter) Summary: test_grp failure on Mac OS X Initial Comment: I noticed that test_grp began failing for me on Mac OS X. I thought perhaps it was related to the changes Martin checked in for grpmodule.c Saturday (May 3rd) for OpenVMS, but a Python executable built on May 2nd also fails to pass the test. However, it passes using 2.2.2 (running against the 2.2.2 version of the test). % ./python.exe ../Lib/test/test_grp.py test_errors (__main__.GroupDatabaseTestCase) ... ok test_values (__main__.GroupDatabaseTestCase) ... FAIL =========================================== =========================== FAIL: test_values (__main__.GroupDatabaseTestCase) ----------------------------------------------------------- ----------- Traceback (most recent call last): File "../Lib/test/test_grp.py", line 46, in test_values self.assert_(max([self.valueseq(e2, x) \ File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError ----------------------------------------------------------- ----------- Ran 2 tests in 0.162s FAILED (failures=1) Traceback (most recent call last): File "../Lib/test/test_grp.py", line 103, in ? test_main() File "../Lib/test/test_grp.py", line 100, in test_main test_support.run_unittest(GroupDatabaseTestCase) File "/Users/skip/src/python/head/dist/src/Lib/test/ test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "/Users/skip/src/python/head/dist/src/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_grp.py", line 46, in test_values self.assert_(max([self.valueseq(e2, x) \ File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError I wonder if it's related to Walter's changes to test_grp.py on or about versions 1.14 or 1.15? Here's a session transcript which shows a couple problems. "ebygid" is a dict like entriesbygid in test_grp.py. "entries" is the output of grp.getgrall(). >>> pprint.pprint(ebygid) {-2: [('nobody', '*', -2, [])], -1: [('nogroup', '*', -1, [])], 0: [('wheel', '*', 0, ['skip'])], 1: [('daemon', '*', 1, ['root'])], 2: [('kmem', '*', 2, ['root'])], 3: [('sys', '*', 3, ['root'])], 4: [('tty', '*', 4, ['root'])], 5: [('operator', '*', 5, ['root'])], 6: [('mail', '*', 6, [])], 7: [('bin', '*', 7, [])], 20: [('staff', '*', 20, ['root'])], 25: [('smmsp', '*', 25, [])], 31: [('guest', '*', 31, ['root'])], 45: [('utmp', '*', 45, [])], 66: [('uucp', '*', 66, [])], 68: [('dialer', '*', 68, [])], 69: [('network', '*', 69, [])], 70: [('www', '*', 70, [])], 75: [('sshd', '*', 75, [])], 80: [('admin', '*', 80, ['root', 'skip'])], 99: [('unknown', '*', 99, [])], 250: [('news', '*', 250, [])], 251: [('mysql', '*', 251, [])], 252: [('pgsql', '*', 252, []), ('postgres', '*', 252, ['skip'])], 253: [('games', '*', 253, [])], 254: [('canna', '*', 254, [])], 255: [('postfix', '*', 255, [])], 256: [('maildrop', '*', 256, [])], 257: [('tomcat', '*', 257, [])], 258: [('jabber', '*', 258, [])], 259: [('opennms', '*', 259, [])], 260: [('clamav', '*', 260, [])]} >>> for e in entries: ... e2 = grp.getgrgid (e.gr_gid) ... print e2 ... print [veq(e2, x) for x in ebygid[e.gr_gid]] ... ('nobody', '', -2, []) [True] ('nogroup', '', -1, []) [True] ('wheel', '', 0, ['skip']) [True] ('daemon', '', 1, ['root']) [True] ('kmem', '', 2, ['root']) [True] ('sys', '', 3, ['root']) [True] ('tty', '', 4, ['root']) [True] ('operator', '', 5, ['root']) [True] ('mail', '', 6, []) [True] ('bin', '', 7, []) [True] ('staff', '', 20, ['root']) [True] ('guest', '', 31, ['root']) [True] ('utmp', '', 45, []) [True] ('uucp', '', 66, []) [True] ('dialer', '', 68, []) [True] ('network', '', 69, []) [True] ('www', '', 70, []) [True] ('admin', '', 80, ['root', 'skip']) [True] ('unknown', '', 99, []) [True] ('smmsp', '', 25, []) [True] ('mysql', '', 251, []) [True] ('sshd', '', 75, []) [True] ('news', '', 250, []) [True] ('pgsql', '', 252, ['skip']) [False, False] ('games', '', 253, []) [True] ('canna', '', 254, []) [True] ('postfix', '', 255, []) [True] ('maildrop', '', 256, []) [True] ('tomcat', '', 257, []) [True] ('jabber', '', 258, []) [True] ('opennms', '', 259, []) [True] ('clamav', '', 260, []) [True] ('pgsql', '', 252, ['skip']) [False, False] I think it arises from the fact that on my machine I have two group entries with the same id but different names (pgsql and postgres). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-05 21:47 Message: Logged In: YES user_id=89016 I think I have a fix for that (basically by removing the check whether a tuple similar to the one from pwd.getgrgid() is among those for the same gid returned by pwd.getgrall()). Unfortunately CVS says "Connection refused" today. I'll try again tomorrow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732783&group_id=5470 From noreply@sourceforge.net Mon May 5 21:34:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 13:34:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable Message-ID: Bugs item #731501, was opened at 2003-05-02 19:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Nick Vargish (vargish) Assigned to: Skip Montanaro (montanaro) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 22:34 Message: Logged In: YES user_id=21627 I can't actually test the patch, but it looks good to me. Please apply! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 16:27 Message: Logged In: YES user_id=44345 I believe the attached patch does what's necessary to get this to work again. It does a few things: * setup.py builds the bsddb185 under the right (restrictive) circumstances. /usr/include/db.h must exist and HASHVERSION must be 2. In this case the bsddb185 module will be built without any extra includes, libraries or #defines, forcing whatever is present in /usr/include/db.h and libc to be used to build the module. * whichdb.py detects the older hash file format and returns "bsddb185". * bsddbmodule.c grows an extra undocumented attribute, "open". The last two changes avoid having to change dbhash.py in complicated ways to distinguish between new and old file versions. The format- detecting mess remains isolated to whichdb.py. Using this setup I was successfully able to open /etc/pwd.db on my system using anydbm.open(), which I was unable to do previously. I can also still open a more recent hash file created with anydbm.open. Finally, new files created with anydbm.open are in the later format. Please give it a try. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:02 Message: Logged In: YES user_id=21627 I think this is not a bug. open() has determined that this is a bsddb file, but bsddb is not supported on the system. Or did you mean to suggest that opening the very same file with dbm would be successful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 From noreply@sourceforge.net Mon May 5 22:55:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 14:55:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable Message-ID: Bugs item #731501, was opened at 2003-05-02 19:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Nick Vargish (vargish) Assigned to: Skip Montanaro (montanaro) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 23:55 Message: Logged In: YES user_id=21627 Actually, you probably need to check whether /usr/lib/libdb.* is present, and link with that as well if it is. If you are uncertain whether this is the right library, I see no way except to run a test program, at configure time, that creates a database and determines whether this really is a DB 1.85 database. Alternatively, the test program might try to invoke db_version. If the function is available, it is DB x, x>=2 (DB1 apparently has no version indication function). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 22:34 Message: Logged In: YES user_id=21627 I can't actually test the patch, but it looks good to me. Please apply! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 16:27 Message: Logged In: YES user_id=44345 I believe the attached patch does what's necessary to get this to work again. It does a few things: * setup.py builds the bsddb185 under the right (restrictive) circumstances. /usr/include/db.h must exist and HASHVERSION must be 2. In this case the bsddb185 module will be built without any extra includes, libraries or #defines, forcing whatever is present in /usr/include/db.h and libc to be used to build the module. * whichdb.py detects the older hash file format and returns "bsddb185". * bsddbmodule.c grows an extra undocumented attribute, "open". The last two changes avoid having to change dbhash.py in complicated ways to distinguish between new and old file versions. The format- detecting mess remains isolated to whichdb.py. Using this setup I was successfully able to open /etc/pwd.db on my system using anydbm.open(), which I was unable to do previously. I can also still open a more recent hash file created with anydbm.open. Finally, new files created with anydbm.open are in the later format. Please give it a try. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:02 Message: Logged In: YES user_id=21627 I think this is not a bug. open() has determined that this is a bsddb file, but bsddb is not supported on the system. Or did you mean to suggest that opening the very same file with dbm would be successful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 From noreply@sourceforge.net Mon May 5 23:35:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 05 May 2003 15:35:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-732951 ] bsddb.*open mode should default to 'r' rather than 'c' Message-ID: Bugs item #732951, was opened at 2003-05-05 17:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732951&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb.*open mode should default to 'r' rather than 'c' Initial Comment: In module bsddb, the second argument of the open functions (e.g., btopen) should default to 'r' rather than 'c'. Most (all?) of the other open functions, both in the various dbm-like modules and for basic I/O default this way. If this change is not made, then at least this behavior should be documented clearly. Currently it's not documented at all (as far as I can find). Cheers, Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732951&group_id=5470 From noreply@sourceforge.net Tue May 6 08:37:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 00:37:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: Bugs item #729317, was opened at 2003-04-28 22:41 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Larry Bugbee (thunderbug) Assigned to: Eric S. Raymond (esr) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a and _tkinter.TCL_VERSION is a Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 00:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Tue May 6 08:38:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 00:38:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-726446 ] textwrap.wrap infinite loop Message-ID: Bugs item #726446, was opened at 2003-04-23 13:59 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Jason Petrone (jpetrone) Assigned to: Greg Ward (gward) Summary: textwrap.wrap infinite loop Initial Comment: textwrap.wrap appears to go into an infinite loop when called with a width <= 0. I don't know what the correct behavior here should be, but I'm guessing this isn't it. Maybe it should be throwing an exception? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470 From noreply@sourceforge.net Tue May 6 08:43:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 00:43:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-705792 ] test_atexit fails in directories with spaces Message-ID: Bugs item #705792, was opened at 2003-03-18 14:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470 Category: None Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) >Assigned to: Raymond Hettinger (rhettinger) Summary: test_atexit fails in directories with spaces Initial Comment: The regression test program test_atexit.py constructs a command line without doing any quoting of arguments. If the name of the build directory contains spaces, the command doesn't work and the test fails. Here's what happens in Windows: H:\benh\My Documents\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d test_atexit.py Adding parser accelerators ... Done. Traceback (most recent call last): File "test_atexit.py", line 33, in ? """) File "test_support.py", line 122, in vereq raise TestFailed, "%r == %r" % (a, b) test_support.TestFailed: '' == "handler2 (7,) {'kw': 'abc'}\nhandler2 () {}\nhandler1\n" [5168 refs] If I change the current directory to use a compatibility name without a space in it: H:\benh\My Documents\python\Python-2.2.2\Lib\test>cd h:\benh\mydocu~1\python\python-2.2.2\lib\test H:\benh\MYDOCU~1\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d test_atexit.py Adding parser accelerators ... Done. [5168 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 19:42 Message: Logged In: YES user_id=33168 Directories with spaces should work with current CVS. The fix needs to be backported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470 From noreply@sourceforge.net Tue May 6 08:50:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 00:50:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 11:45 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) >Assigned to: Guido van Rossum (gvanrossum) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 12:20 Message: Logged In: YES user_id=80475 This was an intentional change. The idea was to make sure that calls to iter() would respect an overriden __getitem__() method. We're taking another look at the decision and thinking about whether it made sense with respect to least surprise, utility, consistency, and performance. ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-01 08:58 Message: Logged In: YES user_id=142817 Thanks for pointing this prior bug report to me. I found the discussions very insightful. Regarding the changes made to __iter__, I have no problems from an application point of view. I just need to know the designed behavior and adjust my code accordingly. From a philosophical point of view, I have mixed feelings about making __iter__ depend upon an overridden __getitem__. I can see the advantages of simplicity in writing extension classes, but you also lose access to the base __iter__ functionality, although I cannot think of an example of where that would be important off the top of my head. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 07:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Tue May 6 10:02:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 02:02:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-692959 ] new.function ignores keyword arguments Message-ID: Bugs item #692959, was opened at 2003-02-25 10:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692959&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new.function ignores keyword arguments Initial Comment: it's no biggie, but: >>> import new >>> new.function(a=1) Traceback (most recent call last): File "", line 1, in ? TypeError: function() takes at least 2 arguments (0 given) is kind of sucky. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 04:02 Message: Logged In: YES user_id=80475 Fixed. See Objects/funcobject.c 2.62 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692959&group_id=5470 From noreply@sourceforge.net Tue May 6 11:52:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 03:52:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-733199 ] OSX installer problem with pydoc Message-ID: Bugs item #733199, was opened at 2003-05-06 12:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733199&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: OSX installer problem with pydoc Initial Comment: >From Bob Talbert: Just a quick note that the pydoc that gets installed as part of 2.3b1 has a typo in the #! line. Can't quite see why it is hardcoded this way, but the line reads: #!/tmp/_py/install/Library/Frameworks/Python.framework/Versions/ 2.3/bin/python when it should be: #!/Library/Frameworks/Python.framework/Versions/2.3/bin/python ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733199&group_id=5470 From noreply@sourceforge.net Tue May 6 12:23:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 04:23:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-730506 ] wdg["textvariable"] and setvar/getvar not compatible Message-ID: Bugs item #730506, was opened at 2003-05-01 01:56 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: wdg["textvariable"] and setvar/getvar not compatible Initial Comment: In Python 2.2.2 and earlier, one could do: root = Tk() v = StringVar() l = Label(root, textvariable=v) l["textvariable"] and get back the name of the variable. This could then be used in l.setvar() and l.getvar() to set or get that variable. Such code is broken in Python 2.3b1 because l["textvariable"] returns a tcl object, and setvar/getvar don't recognize it. It's worth fixing because setvar and getvar seem to be the only way to deal with the thing returned by l["textvariable"]. A fix to consider is to enhance setvar and getvar so that they can deal with tcl objects (as well as with names of variables). This would still break any code that demanded a string back, but the usual reason to obtain the variable was to set or get it with setvar or getvar. So I think it would handle most problems. A less interesting fix is to have l["textvariable"] return a string. (Of course users can also disable returning objects.) A broader fix is to have l["textvariable"] return the original Tkinter Variable. That'd be truly wonderful. It would eliminate the need for setvar or getvar in all but the strangest cases (and the existing implementation would do fine in all others). It would certainly break some existing code (users would would have to disable returning objects to be fix that), but what better time to introduce it then when Tkinter is actually returning non-strings sometimes? I know I'm dreaming. I looked at Tkinter.py and it doesn't look like much fun to add (though it could be done by keeping a reference in the Tk object). -- Russell ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-06 13:23 Message: Logged In: YES user_id=45365 Tkinter now doesn't work anymore on MacOSX, at least not with Aqua Tk (the only one I tried), and I think this fix is to blame. Calling Tkinter.Tk() aborts with a RuntimeError: tcl.h version (8.4) doesn't match libtcl.a version (8.4) Inspection reveals that _tkinter.TCL_VERSION is the string "8.4", whereas self.tk.getvar('tcl_version') is the floating point number 8.4000000000000004. This specific bug can be fixed by comparing to str(tcl_version), but I'm not sure whether this is the right fix, more similar problems could be lurking out there. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-01 07:50 Message: Logged In: YES user_id=21627 This is fixed in _tkinter.c 1.156, by having getvar/setvar accept tcl objects. Your desired behaviour of having ["textvariable"] return a Variable object would break your own code, as setvar would again complain about a type error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 From noreply@sourceforge.net Tue May 6 12:47:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 04:47:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 12:45 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Guido van Rossum (gvanrossum) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 07:47 Message: Logged In: YES user_id=6380 The more I think about it, the more I think that list.__iter__ over a list subclass instance should give you the items of the underlying list, and not respect any overrides of __getitem__. That means that you only have to override __iter__ if your __getitem__ reorders items or hides some, not if it simply renumbers them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 13:20 Message: Logged In: YES user_id=80475 This was an intentional change. The idea was to make sure that calls to iter() would respect an overriden __getitem__() method. We're taking another look at the decision and thinking about whether it made sense with respect to least surprise, utility, consistency, and performance. ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-01 09:58 Message: Logged In: YES user_id=142817 Thanks for pointing this prior bug report to me. I found the discussions very insightful. Regarding the changes made to __iter__, I have no problems from an application point of view. I just need to know the designed behavior and adjust my code accordingly. From a philosophical point of view, I have mixed feelings about making __iter__ depend upon an overridden __getitem__. I can see the advantages of simplicity in writing extension classes, but you also lose access to the base __iter__ functionality, although I cannot think of an example of where that would be important off the top of my head. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 08:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Tue May 6 13:21:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 05:21:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-733231 ] Need an easy way to check the version Message-ID: Bugs item #733231, was opened at 2003-05-06 14:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733231&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Need an easy way to check the version Initial Comment: With MacPython's Package Manager being able to install the full HTML documentation on the users' machine it would be nice if it could check the version of the documentation. Something like a version.txt (or __version__.py?) should do the trick. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733231&group_id=5470 From noreply@sourceforge.net Tue May 6 14:46:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 06:46:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-728574 ] Long file names in osa suites Message-ID: Bugs item #728574, was opened at 2003-04-27 22:26 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728574&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Long file names in osa suites Initial Comment: Some of the standard osa suite modules have filenames that are too long for MacOS9. This needs to be fixed. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-06 15:46 Message: Logged In: YES user_id=45365 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728574&group_id=5470 From noreply@sourceforge.net Tue May 6 15:28:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 07:28:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-731643 ] IDE "lookup in documentation" doesn't work in interactive wi Message-ID: Bugs item #731643, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731643&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: IDE "lookup in documentation" doesn't work in interactive wi Initial Comment: The Help->Lookup in Documentation picks up the selection in edit windows, but it doesn't do this in the Interactive window (and I wouldn't be surprised if it also doesn't work in the output window). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-06 16:28 Message: Logged In: YES user_id=45365 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731643&group_id=5470 From noreply@sourceforge.net Tue May 6 18:27:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 10:27:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-730506 ] wdg["textvariable"] and setvar/getvar not compatible Message-ID: Bugs item #730506, was opened at 2003-05-01 01:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: wdg["textvariable"] and setvar/getvar not compatible Initial Comment: In Python 2.2.2 and earlier, one could do: root = Tk() v = StringVar() l = Label(root, textvariable=v) l["textvariable"] and get back the name of the variable. This could then be used in l.setvar() and l.getvar() to set or get that variable. Such code is broken in Python 2.3b1 because l["textvariable"] returns a tcl object, and setvar/getvar don't recognize it. It's worth fixing because setvar and getvar seem to be the only way to deal with the thing returned by l["textvariable"]. A fix to consider is to enhance setvar and getvar so that they can deal with tcl objects (as well as with names of variables). This would still break any code that demanded a string back, but the usual reason to obtain the variable was to set or get it with setvar or getvar. So I think it would handle most problems. A less interesting fix is to have l["textvariable"] return a string. (Of course users can also disable returning objects.) A broader fix is to have l["textvariable"] return the original Tkinter Variable. That'd be truly wonderful. It would eliminate the need for setvar or getvar in all but the strangest cases (and the existing implementation would do fine in all others). It would certainly break some existing code (users would would have to disable returning objects to be fix that), but what better time to introduce it then when Tkinter is actually returning non-strings sometimes? I know I'm dreaming. I looked at Tkinter.py and it doesn't look like much fun to add (though it could be done by keeping a reference in the Tk object). -- Russell ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-06 19:27 Message: Logged In: YES user_id=21627 This patch is likely *not* the cause of this problem. The comparison only involves a single call to getvar, and that uses a string argument. This patch didn't affect the result of getvar at all. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-06 13:23 Message: Logged In: YES user_id=45365 Tkinter now doesn't work anymore on MacOSX, at least not with Aqua Tk (the only one I tried), and I think this fix is to blame. Calling Tkinter.Tk() aborts with a RuntimeError: tcl.h version (8.4) doesn't match libtcl.a version (8.4) Inspection reveals that _tkinter.TCL_VERSION is the string "8.4", whereas self.tk.getvar('tcl_version') is the floating point number 8.4000000000000004. This specific bug can be fixed by comparing to str(tcl_version), but I'm not sure whether this is the right fix, more similar problems could be lurking out there. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-01 07:50 Message: Logged In: YES user_id=21627 This is fixed in _tkinter.c 1.156, by having getvar/setvar accept tcl objects. Your desired behaviour of having ["textvariable"] return a Variable object would break your own code, as setvar would again complain about a type error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 From noreply@sourceforge.net Tue May 6 18:48:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 10:48:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-730506 ] wdg["textvariable"] and setvar/getvar not compatible Message-ID: Bugs item #730506, was opened at 2003-04-30 16:56 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: wdg["textvariable"] and setvar/getvar not compatible Initial Comment: In Python 2.2.2 and earlier, one could do: root = Tk() v = StringVar() l = Label(root, textvariable=v) l["textvariable"] and get back the name of the variable. This could then be used in l.setvar() and l.getvar() to set or get that variable. Such code is broken in Python 2.3b1 because l["textvariable"] returns a tcl object, and setvar/getvar don't recognize it. It's worth fixing because setvar and getvar seem to be the only way to deal with the thing returned by l["textvariable"]. A fix to consider is to enhance setvar and getvar so that they can deal with tcl objects (as well as with names of variables). This would still break any code that demanded a string back, but the usual reason to obtain the variable was to set or get it with setvar or getvar. So I think it would handle most problems. A less interesting fix is to have l["textvariable"] return a string. (Of course users can also disable returning objects.) A broader fix is to have l["textvariable"] return the original Tkinter Variable. That'd be truly wonderful. It would eliminate the need for setvar or getvar in all but the strangest cases (and the existing implementation would do fine in all others). It would certainly break some existing code (users would would have to disable returning objects to be fix that), but what better time to introduce it then when Tkinter is actually returning non-strings sometimes? I know I'm dreaming. I looked at Tkinter.py and it doesn't look like much fun to add (though it could be done by keeping a reference in the Tk object). -- Russell ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2003-05-06 10:48 Message: Logged In: YES user_id=431773 Thank you very much for the fix! I do wish to respond to the comment "Your desired behaviour of having ["textvariable"] return a Variable object would break your own code, as setvar would again complain about a type error." str(var) returns the name of the underlying tk variable, whether var is a Tkinter Variable or a tcl object. Thus within setvar and getvar one can simply take str(arg) before using it to solve both the original bug report and also my suggested change. I plan to submit a patch to Tkinter that implements my suggested behavior and I'd hate for folks to think that it was a radical departure. In fact it is only slightly different than the current new behavior of returning a tcl object and potentially has the same solution for getvar and setvar. One gets an object back either way. The Python 2.3b1 behavior is to return an opaque tcl object; my suggestion is simply to return a non-opaque Tkinter Variable object instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-06 10:27 Message: Logged In: YES user_id=21627 This patch is likely *not* the cause of this problem. The comparison only involves a single call to getvar, and that uses a string argument. This patch didn't affect the result of getvar at all. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-06 04:23 Message: Logged In: YES user_id=45365 Tkinter now doesn't work anymore on MacOSX, at least not with Aqua Tk (the only one I tried), and I think this fix is to blame. Calling Tkinter.Tk() aborts with a RuntimeError: tcl.h version (8.4) doesn't match libtcl.a version (8.4) Inspection reveals that _tkinter.TCL_VERSION is the string "8.4", whereas self.tk.getvar('tcl_version') is the floating point number 8.4000000000000004. This specific bug can be fixed by comparing to str(tcl_version), but I'm not sure whether this is the right fix, more similar problems could be lurking out there. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-30 22:50 Message: Logged In: YES user_id=21627 This is fixed in _tkinter.c 1.156, by having getvar/setvar accept tcl objects. Your desired behaviour of having ["textvariable"] return a Variable object would break your own code, as setvar would again complain about a type error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 From noreply@sourceforge.net Tue May 6 21:00:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 13:00:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-678250 ] test_mmap failling on AIX Message-ID: Bugs item #678250, was opened at 2003-01-31 12: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=678250&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_mmap failling on AIX Initial Comment: test_mmap is failing on a flush while trying to do: Copy-on-write memory map data not written correctly The problem is that the mmap is opened with ACCESS_COPY. This translates to MAP_PRIVATE. On AIX, the msync man page says: "When the MS_SYNC and MAP_PRIVATE flags both are used, the msync subroutine returns an errno value of EINVAL." I'm not sure what the correct fix should be. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-06 16:00 Message: Logged In: YES user_id=31435 Hmm. I suspect the flush docs() are too strong (does flush really promise to materialize bytes *on disk*? it doesn't for other Python file objects, you also need os.fsync() for that). Your point is well taken, though, and whatever flush() does normally do, it's not going to do it for a copy-on-write mmap. So fine by me if we declare that attempting to flush() a copy- on-write mmap raises an exception. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 06:09 Message: Logged In: YES user_id=21627 The documentation for flush says "Flushes changes made to the in-memory copy of a file back to disk." But it doesn't do that, and we all agree it shouldn't do that. So I would claim that it is an error to use .flush on an mmap object that was opened in ACCESS_COPY. This is like trying to write to a file that was opened for reading only: one *could* declare that the write just does nothing, but it helps the developer more if you get an exception, because the code is likely wrong (i.e. not following the likely intentions of the author). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-28 15:55 Message: Logged In: YES user_id=31435 Sorry, I've had nothing to do with mmap beyond fixing bugs. The "access" feature was due to Jay Miller, although I believe I checked in his patch. Martin, I don't understand why you think it's reasonable for flush to complain here: the mmap is open for writing, so what's surprising about expecting to be able to flush after a write? Simply that there's no associated file, due to copy-on- write? Then user code would have to be acutely aware of how an mmap'ed object was opened, just to avoid nuisance complaints when they flush after writing. So that's a third alternative: alter the implementation to make mmap.flush() do nothing when an mmap object was opened as copy-on-write. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 02:00 Message: Logged In: YES user_id=21627 I think the test is somewhat bogus: It tries to check that modification to an ACCESS_COPY doesn't modify the underlying file, but assumes that .flush becomes a no-op, even though an exception is more reasonable (IMO; errors should never pass silently). So I see two options: Declare that .flush() always raises an exception (and modify implementations that don't produce an exception accordingly), or declare that aspect to be system-dependent, and modify the test (and the documentation) to expect and ignore an exception. Assigning to Tim, as he incorporated that feature into mmap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 From noreply@sourceforge.net Tue May 6 21:18:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 13:18:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-06 21:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 01:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 18:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 09:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 16:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 16:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 21:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 21:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 21:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 20:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Tue May 6 21:54:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 13:54:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable Message-ID: Bugs item #731501, was opened at 2003-05-02 12:56 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Nick Vargish (vargish) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-06 15:54 Message: Logged In: YES user_id=44345 Assigned to Fred for doc review - I added a couple notes to libbsddb.tex and libundoc.tex in lieu of actually creating a separate bsddb185 section which I felt would have given people the mistaken idea that the module is available for general use. Still, I thought there should be some mention in the docs. Library detection probably needs a little tweakage as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 16:55 Message: Logged In: YES user_id=21627 Actually, you probably need to check whether /usr/lib/libdb.* is present, and link with that as well if it is. If you are uncertain whether this is the right library, I see no way except to run a test program, at configure time, that creates a database and determines whether this really is a DB 1.85 database. Alternatively, the test program might try to invoke db_version. If the function is available, it is DB x, x>=2 (DB1 apparently has no version indication function). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 15:34 Message: Logged In: YES user_id=21627 I can't actually test the patch, but it looks good to me. Please apply! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 09:27 Message: Logged In: YES user_id=44345 I believe the attached patch does what's necessary to get this to work again. It does a few things: * setup.py builds the bsddb185 under the right (restrictive) circumstances. /usr/include/db.h must exist and HASHVERSION must be 2. In this case the bsddb185 module will be built without any extra includes, libraries or #defines, forcing whatever is present in /usr/include/db.h and libc to be used to build the module. * whichdb.py detects the older hash file format and returns "bsddb185". * bsddbmodule.c grows an extra undocumented attribute, "open". The last two changes avoid having to change dbhash.py in complicated ways to distinguish between new and old file versions. The format- detecting mess remains isolated to whichdb.py. Using this setup I was successfully able to open /etc/pwd.db on my system using anydbm.open(), which I was unable to do previously. I can also still open a more recent hash file created with anydbm.open. Finally, new files created with anydbm.open are in the later format. Please give it a try. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 04:02 Message: Logged In: YES user_id=21627 I think this is not a bug. open() has determined that this is a bsddb file, but bsddb is not supported on the system. Or did you mean to suggest that opening the very same file with dbm would be successful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&group_id=5470 From noreply@sourceforge.net Tue May 6 21:51:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 13:51:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-06 22:51 Message: Logged In: YES user_id=92689 Here's a new attempt. Martin and I went back and forth a few times, and what I now ended up with isn't all _that_ different from the initial patch, except it no longer uses wrapped functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 23:45 Message: Logged In: YES user_id=21627 The patch is incorrect: usage of locked getaddrinfo depends on whether gethostbyname_r is supported on the platform. However, this is unrelated: A platform may have gethostbyname_r, and still not provide a thread-safe getaddrinfo, or it may not have gethostbyname_r, and yet provide a thread-safe getaddrinfo. I suggest you separate issues: 1. Should the lock variable be declared and initialized? You have two options: a) only create if needed (see below), or b) always create if Python is threaded 2. Should getaddrinfo use the lock? In general, it shouldn't, except for a few known-bad systems. 3. Should gethostbyname use the lock? Yes, unless the reentrant versions of this function are used. Notice that for Windows, gethostbyname itself is thread-safe, as it allocates a thread-local hostent. I think the lock management code is also incorrect: There is a certain moment after getaddrinfo returns where neither the GIL nor the getaddrinfo lock is held, yet Python accesses the getaddrinfo result afterwards. If getaddrinfo returns a pointer to global data, a second call could modify the result even though we have not processed it yet. I'm not sure how to solve this. It is probably safest to keep the getaddrinfo lock until freeaddrinfo has been called. Also, for systems that don't lock getaddrinfo, I would prefer if py_getaddrinfo was a define for getaddrinfo. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 20:02 Message: Logged In: YES user_id=92689 I've attached a first cut of a patch. It implements wrappers for getaddrinfo and getnameinfo, to take the burden of dealing with the lock and the GIL away from the caller. As suggested by MvL in prvt mail, I've simply reused the existing gethostbyname lock, but renamed it to netdb_lock. What needs to be reviewed carefully is when exactly USE_NETDB_LOCK (formerly known as USE_GETHOSTBYNAME_LOCK) is defined. It happens to be defined for my platform, so it "works for me". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 16:00 Message: Logged In: YES user_id=21627 Mark: the original complaint came from BSD users. So if we only release the GIL on a "good" platform, the BSD users aren't helped. Likewise, unless compiled by VC7.x, Windows users are not helped, since Python would use the getaddrinfo emulation. So if this as attempted, I think we need a best-effort solution for all systems. You could look at the Tcl lock. I recommend you look at the 2.2 sources, since the Tcl lock logic got more complicated recently (as Tcl now also has a multi-threaded mode of operation). If your platform is Mac OS X, don't trust that it is too BSDish in this respect. If both FreeBSD and NeXT had some function, Apple apparently has always chosen the NeXT version. getaddrinfo was one such case. But then, it appears that the NeXT version is even worse than the FreeBSD version. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:56 Message: Logged In: YES user_id=92689 (Never mind, I found plenty of examples in sockemodule.c itself.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:40 Message: Logged In: YES user_id=92689 Since my platform is BSD-ish, I want a lock ;-) Yes, I would like to work on a patch, except I will need some hand-holding, as I've never done anything with threads from C. Can you point me to examples of such a lock in the Python source code? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-03 14:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Tue May 6 23:00:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 15:00:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: Bugs item #729317, was opened at 2003-04-28 22:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) >Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a and _tkinter.TCL_VERSION is a Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 17:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 00:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Tue May 6 23:31:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 15:31:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 11:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Guido van Rossum (gvanrossum) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 17:31 Message: Logged In: YES user_id=80475 I concur. Would you like me to revert the changes (2 lines each to listobject.c and tupleobject.c)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 06:47 Message: Logged In: YES user_id=6380 The more I think about it, the more I think that list.__iter__ over a list subclass instance should give you the items of the underlying list, and not respect any overrides of __getitem__. That means that you only have to override __iter__ if your __getitem__ reorders items or hides some, not if it simply renumbers them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 12:20 Message: Logged In: YES user_id=80475 This was an intentional change. The idea was to make sure that calls to iter() would respect an overriden __getitem__() method. We're taking another look at the decision and thinking about whether it made sense with respect to least surprise, utility, consistency, and performance. ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-01 08:58 Message: Logged In: YES user_id=142817 Thanks for pointing this prior bug report to me. I found the discussions very insightful. Regarding the changes made to __iter__, I have no problems from an application point of view. I just need to know the designed behavior and adjust my code accordingly. From a philosophical point of view, I have mixed feelings about making __iter__ depend upon an overridden __getitem__. I can see the advantages of simplicity in writing extension classes, but you also lose access to the base __iter__ functionality, although I cannot think of an example of where that would be important off the top of my head. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 07:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Wed May 7 01:30:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 17:30:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-726446 ] textwrap.wrap infinite loop Message-ID: Bugs item #726446, was opened at 2003-04-23 13:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Jason Petrone (jpetrone) Assigned to: Greg Ward (gward) Summary: textwrap.wrap infinite loop Initial Comment: textwrap.wrap appears to go into an infinite loop when called with a width <= 0. I don't know what the correct behavior here should be, but I'm guessing this isn't it. Maybe it should be throwing an exception? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 19:30 Message: Logged In: YES user_id=80475 Greg, do you have time for this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470 From noreply@sourceforge.net Wed May 7 01:31:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 17:31:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 12:45 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) >Assigned to: Raymond Hettinger (rhettinger) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 20:31 Message: Logged In: YES user_id=6380 Yes, please. Thanks for hanging on to this until I saw the error of my way. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 18:31 Message: Logged In: YES user_id=80475 I concur. Would you like me to revert the changes (2 lines each to listobject.c and tupleobject.c)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 07:47 Message: Logged In: YES user_id=6380 The more I think about it, the more I think that list.__iter__ over a list subclass instance should give you the items of the underlying list, and not respect any overrides of __getitem__. That means that you only have to override __iter__ if your __getitem__ reorders items or hides some, not if it simply renumbers them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 13:20 Message: Logged In: YES user_id=80475 This was an intentional change. The idea was to make sure that calls to iter() would respect an overriden __getitem__() method. We're taking another look at the decision and thinking about whether it made sense with respect to least surprise, utility, consistency, and performance. ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-01 09:58 Message: Logged In: YES user_id=142817 Thanks for pointing this prior bug report to me. I found the discussions very insightful. Regarding the changes made to __iter__, I have no problems from an application point of view. I just need to know the designed behavior and adjust my code accordingly. From a philosophical point of view, I have mixed feelings about making __iter__ depend upon an overridden __getitem__. I can see the advantages of simplicity in writing extension classes, but you also lose access to the base __iter__ functionality, although I cannot think of an example of where that would be important off the top of my head. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 08:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Wed May 7 01:37:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 17:37:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-697990 ] Document strptime limitation Message-ID: Bugs item #697990, was opened at 2003-03-05 05:48 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 Category: Documentation Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Brett Cannon (bcannon) Summary: Document strptime limitation Initial Comment: Python Library Reference, Chapter 6.9: strptime: Many (at least glibc 2) versions of strptime can't parse the time zone (which strftime prints with %Z). This should be mentioned as a warning in the documentation. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-06 17:37 Message: Logged In: YES user_id=357491 I will add some note, but I don't know what yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 From noreply@sourceforge.net Wed May 7 01:56:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 17:56:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-726446 ] textwrap.wrap infinite loop Message-ID: Bugs item #726446, was opened at 2003-04-23 14:59 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Jason Petrone (jpetrone) Assigned to: Greg Ward (gward) Summary: textwrap.wrap infinite loop Initial Comment: textwrap.wrap appears to go into an infinite loop when called with a width <= 0. I don't know what the correct behavior here should be, but I'm guessing this isn't it. Maybe it should be throwing an exception? ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2003-05-06 20:56 Message: Logged In: YES user_id=14422 OK, that's pretty easy to check. Test added in rev 1.20 of Lib/test/test_textwrap.py, fix in rev 1.25 of Lib/textwrap.py . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 20:30 Message: Logged In: YES user_id=80475 Greg, do you have time for this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726446&group_id=5470 From noreply@sourceforge.net Wed May 7 02:10:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 18:10:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 09:45 Message generated for change (Comment added) made by loechelt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Raymond Hettinger (rhettinger) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- >Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-06 18:10 Message: Logged In: YES user_id=142817 Thanks. I personally prefer the previous behavior of 2.2 to the beta. Even though it is slightly more work to override __iter__ (very minimal at that), there are fewer surprises. I think of __getitem__ mapping to [] and not (for x in ...), especially when there is an explicit __iter__ method. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 17:31 Message: Logged In: YES user_id=6380 Yes, please. Thanks for hanging on to this until I saw the error of my way. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 15:31 Message: Logged In: YES user_id=80475 I concur. Would you like me to revert the changes (2 lines each to listobject.c and tupleobject.c)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 04:47 Message: Logged In: YES user_id=6380 The more I think about it, the more I think that list.__iter__ over a list subclass instance should give you the items of the underlying list, and not respect any overrides of __getitem__. That means that you only have to override __iter__ if your __getitem__ reorders items or hides some, not if it simply renumbers them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 10:20 Message: Logged In: YES user_id=80475 This was an intentional change. The idea was to make sure that calls to iter() would respect an overriden __getitem__() method. We're taking another look at the decision and thinking about whether it made sense with respect to least surprise, utility, consistency, and performance. ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-01 06:58 Message: Logged In: YES user_id=142817 Thanks for pointing this prior bug report to me. I found the discussions very insightful. Regarding the changes made to __iter__, I have no problems from an application point of view. I just need to know the designed behavior and adjust my code accordingly. From a philosophical point of view, I have mixed feelings about making __iter__ depend upon an overridden __getitem__. I can see the advantages of simplicity in writing extension classes, but you also lose access to the base __iter__ functionality, although I cannot think of an example of where that would be important off the top of my head. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 05:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Wed May 7 02:10:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 18:10:44 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-727898 ] Support for sending multipart form data Message-ID: Feature Requests item #727898, was opened at 2003-04-26 02:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=727898&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: Support for sending multipart form data Initial Comment: This is necessary, and simple. See:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/146306 There should be 0 politics about the lack of this. In response to this if there is some reason you cannot include this code directly into urllib (most likely), please tell me what I can do within the time frame of my reply to 1 email response to get this code included into the python libraries immediately. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-06 21:10 Message: Logged In: YES user_id=33168 The best way to get anything included into python is to submit a patch. The patch needs to be complete and tested with all source code, documentation and tests in a single patch file. The patch should be relative to current cvs. See http://www.python.org/dev/ for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=727898&group_id=5470 From noreply@sourceforge.net Wed May 7 02:12:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 18:12:35 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-726152 ] Website request Message-ID: Feature Requests item #726152, was opened at 2003-04-23 05:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=726152&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Website request Initial Comment: A link to the SourceForge project page on the website would be a big help, especially to those of us who keep getting told to "submit a bug report to the SF tracker" ;-) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-06 21:12 Message: Logged In: YES user_id=33168 There are 2 on this page: http://www.python.org/dev/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=726152&group_id=5470 From noreply@sourceforge.net Wed May 7 02:21:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 18:21:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-596434 ] textwrap has problems wrapping hyphens Message-ID: Bugs item #596434, was opened at 2002-08-17 10:46 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Greg Ward (gward) Summary: textwrap has problems wrapping hyphens Initial Comment: (Greg already knows about this from private mail; this makes it "official".) Long multi-word command-line options (begin with "--" and contain internal "-") inside text may be wrapped badly by textwrap. For example, "--an- option" may become "--\nan-option" or "--an-\ noption". Perhaps words that begin with hyphens should not be wrapped at all? ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2003-05-06 21:21 Message: Logged In: YES user_id=14422 Finally! Fixed in rev 1.26 of Lib/textwrap.py, with tests in rev 1.21 of Lib/test/test_textwrap.py. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2002-09-11 22:06 Message: Logged In: YES user_id=7733 More edge cases came up today. These break at the slashes: "(--option)" --> "(/--/option)" "(--option-opt)" --> "(/--option-/opt)" All but the last of these breaks are bad. Perhaps TextWrapper should have a "break_whitespace_only" option? This would be especially useful for technical text, where breaks at hyphens may change the text's meaning. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2002-08-25 10:29 Message: Logged In: YES user_id=7733 There's still an edge case that gives poor results. Try wrapping "--text--.". It will wrap like "--text/--/.", leaving just the period (".") or the dashes & period ("--.") on the next line. The latter may or may not be a problem, but I'd say wrapping just the sentence-ending period definitely *is* a problem. A more plausible example is "what the--.". ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-08-22 17:04 Message: Logged In: YES user_id=14422 Thanks for the reminder, David! Fixed in Lib/textwrap.py rev 1.14. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470 From noreply@sourceforge.net Wed May 7 02:23:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 18:23:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-729103 ] Cannot retrieve name of super object Message-ID: Bugs item #729103, was opened at 2003-04-28 14:47 Message generated for change (Settings changed) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot retrieve name of super object Initial Comment: I see that in Python 2.3b1 many problems of super have been fixed, but this one is still there: I cannot retrieve the __name__ of a super object. This generates problems with pydoc, for instance: >>> class C(B): ... sup=super(B) >>> help(C) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/site.py", line 293, in __call__ return pydoc.help(*args, **kwds) File "/usr/local/lib/python2.3/pydoc.py", line 1539, in __call__ self.help(request) File "/usr/local/lib/python2.3/pydoc.py", line 1575, in help else: doc(request, 'Help on %s:') File "/usr/local/lib/python2.3/pydoc.py", line 1368, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/usr/local/lib/python2.3/pydoc.py", line 279, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/local/lib/python2.3/pydoc.py", line 1122, in docclass lambda t: t[1] == 'method') File "/usr/local/lib/python2.3/pydoc.py", line 1057, in spill name, mod, object)) File "/usr/local/lib/python2.3/pydoc.py", line 280, in document if inspect.isroutine(object): return self.docroutine(*args) File "/usr/local/lib/python2.3/pydoc.py", line 1145, in docroutine realname = object.__name__ AttributeError: 'super' object has no attribute '__name__' P.S. I seem to remember I already submitted this bug (or feature request, as you wish ;) but I don't find it in bugtracker and I had no feedback; maybe it wasn't sent at all due to some connection problem. If not, please accept my apologies. Michele Simionato ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470 From noreply@sourceforge.net Wed May 7 02:30:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 18:30:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-730296 ] Unexpected Changes in list Iterator Message-ID: Bugs item #730296, was opened at 2003-04-30 11:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Raymond Hettinger (rhettinger) Summary: Unexpected Changes in list Iterator Initial Comment: I encountered an unexpected change in the behavior of the iterator for the built-in list class. I created a subclass of the list class in which a start attribute was added. The intended behavior was to make the list look shorter by "hiding" an arbitrary number of starting elements. The start attribute was used to control the number of hidden elements. In order to make my shifted list class work in my application, I had to override a number of special methods, including the __iter__ method. In Python 2.2.1 and Python 2.3a2, the default __iter__ method indexed over the entire, unshifted list even with other special methods changed to reflect the shifting. Therefore, I had to override the __iter__ method as well. When I tested my application on Python 2.3b1, I encountered an error which I tracked down to my __iter__ method. I found that it had doubled the shift of the starting value. Eventually, I traced this to a change in the behavior of the default __iter__ method of the built-in list class. I was able to recreate the problem with a simple test case. I created a simple shifted list class with a public start attribute, a __len__ method that subtracts start from the length of the list, and a __getitem__ method that adds start to the index during element access. Iteration over the list (using the default __iter__ inherited from list) returns all the elements in Python 2.2.1, but only the elements after the start value in Python 2.3b1. This change in behavior was an unexpected surprise for me! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 20:30 Message: Logged In: YES user_id=80475 Reverted change. Revised unittest accordingly. See: Objects/listobject.c 2.152 Objects/tupleobject.c 2.81 Lib/test/test_types 1.51 Gary, thanks for the bug report. ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-06 20:10 Message: Logged In: YES user_id=142817 Thanks. I personally prefer the previous behavior of 2.2 to the beta. Even though it is slightly more work to override __iter__ (very minimal at that), there are fewer surprises. I think of __getitem__ mapping to [] and not (for x in ...), especially when there is an explicit __iter__ method. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 19:31 Message: Logged In: YES user_id=6380 Yes, please. Thanks for hanging on to this until I saw the error of my way. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 17:31 Message: Logged In: YES user_id=80475 I concur. Would you like me to revert the changes (2 lines each to listobject.c and tupleobject.c)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-06 06:47 Message: Logged In: YES user_id=6380 The more I think about it, the more I think that list.__iter__ over a list subclass instance should give you the items of the underlying list, and not respect any overrides of __getitem__. That means that you only have to override __iter__ if your __getitem__ reorders items or hides some, not if it simply renumbers them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-01 12:20 Message: Logged In: YES user_id=80475 This was an intentional change. The idea was to make sure that calls to iter() would respect an overriden __getitem__() method. We're taking another look at the decision and thinking about whether it made sense with respect to least surprise, utility, consistency, and performance. ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2003-05-01 08:58 Message: Logged In: YES user_id=142817 Thanks for pointing this prior bug report to me. I found the discussions very insightful. Regarding the changes made to __iter__, I have no problems from an application point of view. I just need to know the designed behavior and adjust my code accordingly. From a philosophical point of view, I have mixed feelings about making __iter__ depend upon an overridden __getitem__. I can see the advantages of simplicity in writing extension classes, but you also lose access to the base __iter__ functionality, although I cannot think of an example of where that would be important off the top of my head. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-01 07:11 Message: Logged In: YES user_id=89016 This is a consequence of the changes done for bug http://www.python.org/sf/665835. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730296&group_id=5470 From noreply@sourceforge.net Wed May 7 03:09:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 19:09:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-596434 ] textwrap has problems wrapping hyphens Message-ID: Bugs item #596434, was opened at 2002-08-17 10:46 Message generated for change (Settings changed) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Greg Ward (gward) Summary: textwrap has problems wrapping hyphens Initial Comment: (Greg already knows about this from private mail; this makes it "official".) Long multi-word command-line options (begin with "--" and contain internal "-") inside text may be wrapped badly by textwrap. For example, "--an- option" may become "--\nan-option" or "--an-\ noption". Perhaps words that begin with hyphens should not be wrapped at all? ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2003-05-06 21:21 Message: Logged In: YES user_id=14422 Finally! Fixed in rev 1.26 of Lib/textwrap.py, with tests in rev 1.21 of Lib/test/test_textwrap.py. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2002-09-11 22:06 Message: Logged In: YES user_id=7733 More edge cases came up today. These break at the slashes: "(--option)" --> "(/--/option)" "(--option-opt)" --> "(/--option-/opt)" All but the last of these breaks are bad. Perhaps TextWrapper should have a "break_whitespace_only" option? This would be especially useful for technical text, where breaks at hyphens may change the text's meaning. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2002-08-25 10:29 Message: Logged In: YES user_id=7733 There's still an edge case that gives poor results. Try wrapping "--text--.". It will wrap like "--text/--/.", leaving just the period (".") or the dashes & period ("--.") on the next line. The latter may or may not be a problem, but I'd say wrapping just the sentence-ending period definitely *is* a problem. A more plausible example is "what the--.". ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-08-22 17:04 Message: Logged In: YES user_id=14422 Thanks for the reminder, David! Fixed in Lib/textwrap.py rev 1.14. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596434&group_id=5470 From noreply@sourceforge.net Wed May 7 03:27:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 19:27:41 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-726152 ] Website request Message-ID: Feature Requests item #726152, was opened at 2003-04-23 04:35 Message generated for change (Comment added) made by david_abrahams You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=726152&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Website request Initial Comment: A link to the SourceForge project page on the website would be a big help, especially to those of us who keep getting told to "submit a bug report to the SF tracker" ;-) ---------------------------------------------------------------------- >Comment By: David Abrahams (david_abrahams) Date: 2003-05-06 21:27 Message: Logged In: YES user_id=52572 Sorry, I meant on the main page. I've never even been tempted to look at the page you cite. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-06 20:12 Message: Logged In: YES user_id=33168 There are 2 on this page: http://www.python.org/dev/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=726152&group_id=5470 From noreply@sourceforge.net Wed May 7 07:10:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 06 May 2003 23:10:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-733667 ] kwargs handled incorrectly Message-ID: Bugs item #733667, was opened at 2003-05-07 00:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: kwargs handled incorrectly Initial Comment: I'm using Python2.3 (first with a1 then tested with CVS version "Python 2.3b1+ (#7, May 6 2003, 23:41:12)" compiled a few minutes ago). There's a bug in how it handles an error condition with keyword arguments. Here's a reproducible Python 2.3b1+ (#7, May 6 2003, 23:41:12) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def add(a, b): ... print "add", repr(a), repr(b) ... return a + b ... >>> add(a=3) add 'a' 3 Traceback (most recent call last): File "", line 1, in ? File "", line 3, in add TypeError: cannot concatenate 'str' and 'int' objects >>> The expected behaviour is what Python 2.2 does, which is >>> def add(a, b): ... return a + b ... >>> add(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: add() takes exactly 2 non-keyword arguments (1 given) >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 From noreply@sourceforge.net Wed May 7 08:54:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 00:54:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-733667 ] kwargs handled incorrectly Message-ID: Bugs item #733667, was opened at 2003-05-07 01:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Andrew Dalke (dalke) >Assigned to: Raymond Hettinger (rhettinger) Summary: kwargs handled incorrectly Initial Comment: I'm using Python2.3 (first with a1 then tested with CVS version "Python 2.3b1+ (#7, May 6 2003, 23:41:12)" compiled a few minutes ago). There's a bug in how it handles an error condition with keyword arguments. Here's a reproducible Python 2.3b1+ (#7, May 6 2003, 23:41:12) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def add(a, b): ... print "add", repr(a), repr(b) ... return a + b ... >>> add(a=3) add 'a' 3 Traceback (most recent call last): File "", line 1, in ? File "", line 3, in add TypeError: cannot concatenate 'str' and 'int' objects >>> The expected behaviour is what Python 2.2 does, which is >>> def add(a, b): ... return a + b ... >>> add(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: add() takes exactly 2 non-keyword arguments (1 given) >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 02:54 Message: Logged In: YES user_id=80475 Ouch! This is a bad one. Bumping up the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 From noreply@sourceforge.net Wed May 7 10:23:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 02:23:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-733667 ] kwargs handled incorrectly Message-ID: Bugs item #733667, was opened at 2003-05-07 01:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Dalke (dalke) Assigned to: Raymond Hettinger (rhettinger) Summary: kwargs handled incorrectly Initial Comment: I'm using Python2.3 (first with a1 then tested with CVS version "Python 2.3b1+ (#7, May 6 2003, 23:41:12)" compiled a few minutes ago). There's a bug in how it handles an error condition with keyword arguments. Here's a reproducible Python 2.3b1+ (#7, May 6 2003, 23:41:12) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def add(a, b): ... print "add", repr(a), repr(b) ... return a + b ... >>> add(a=3) add 'a' 3 Traceback (most recent call last): File "", line 1, in ? File "", line 3, in add TypeError: cannot concatenate 'str' and 'int' objects >>> The expected behaviour is what Python 2.2 does, which is >>> def add(a, b): ... return a + b ... >>> add(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: add() takes exactly 2 non-keyword arguments (1 given) >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 04:23 Message: Logged In: YES user_id=80475 def f(a,b): print a, b def g(a,b,**kw): print a, b, kw f(c=3) # prints c 3 g(c=3) # raises correct error for non-keyword arguments. So, the restated version of the problem is that: when keyword arguments are passed to a function not defining **kw, then the keyword in interpreted as a single for the first positional argument and the keyword value as the second positional argument. Weird and bad! Reverting to earlier versions of getargs.c did not help. Likewise the dict(red=3, blue=4) patch is not the culprit. The prime suspect is now the function call optimizations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 02:54 Message: Logged In: YES user_id=80475 Ouch! This is a bad one. Bumping up the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 From noreply@sourceforge.net Wed May 7 11:03:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 03:03:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-733769 ] test_logging hangs on old RH Linux Message-ID: Bugs item #733769, was opened at 2003-05-07 13: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=733769&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging hangs on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. test_logging hangs after -- log_test3 end --------------------------------------------------- i.e., during the new fancier code for shutting down the tcp server in the finally block at the end of main(). When I run the old test_logging.py from the 2.3a2 distribution using the Python I built from 2.3b1, everything is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733769&group_id=5470 From noreply@sourceforge.net Wed May 7 11:21:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 03:21:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-732761 ] 2.3 breaks email date parsing Message-ID: Bugs item #732761, was opened at 2003-05-05 15:56 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732761&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Berlin (dberlin) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 breaks email date parsing Initial Comment: Parsing dates in emails is broken in 2.3 compared to 2.2.2. Changing parsedate_tz back to what it was in 2.2.2 fixes it. I'm not sure who or why this change was made, but it clearly doesn't handle cases it used to: (oldparseaddr is the 2.3 version with the patch at the bottom applied, which reverts it to what it was in 2.2.2) >>> import _parseaddr >>> _parseaddr.parsedate_tz("3 Mar 2001 02:04:50 -0000") >>> import oldparseaddr >>> oldparseaddr.parsedate_tz("3 Mar 2001 02:04:50 -0000") (2001, 3, 3, 2, 4, 50, 0, 0, 0, 0) >>> The problem is obvious from looking at the new code: The old version would only care if it actually found something it needed to delete. The new version assumes there *must* be a comma in the date if there is no dayname, and if there isn't, returns nothing. I wanted to know if this was a mistake, or done on purpose. If it's a mistake, i'll submit a patch to sourceforge to fix it. Index: _parseaddr.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/email/_parseaddr.py,v retrieving revision 1.5 diff -u -3 -p -r1.5 _parseaddr.py --- _parseaddr.py 17 Mar 2003 18:35:42 -0000 1.5 +++ _parseaddr.py 2 May 2003 15:42:30 -0000 @@ -49,14 +49,9 @@ def parsedate_tz(data): data = data.split() # The FWS after the comma after the day-of-week is optional, so search and # adjust for this. - if data[0].endswith(',') or data[0].lower() in _daynames: + if data[0][-1] in (',', '.') or data[0].lower() in _daynames: # There's a dayname here. Skip it del data[0] - else: - i = data[0].rfind(',') - if i < 0: - return None - data[0] = data[0][i+1:] if len(data) == 3: # RFC 850 date, deprecated stuff = data[0].split('-') if len(stuff) == 3: ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-05-07 10:21 Message: Logged In: YES user_id=75166 The following patch solves the problem and is tolerant of slightly malformed dates with a dayname which is not properly delimted by white space. diff -u -r -P email/_parseaddr.py email-tzp/_parseaddr.py --- email/_parseaddr.py 2003-03-30 21:21:28.000000000 +0100 +++ email-tzp/_parseaddr.py 2003-05-06 21:56:37.000000000 +0100 @@ -54,9 +54,9 @@ del data[0] else: i = data[0].rfind(',') - if i < 0: - return None - data[0] = data[0][i+1:] + if i >= 0: + # There's what may be a dayname here. Skip it + data[0] = data[0][i+1:] if len(data) == 3: # RFC 850 date, deprecated stuff = data[0].split('-') if len(stuff) == 3: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732761&group_id=5470 From noreply@sourceforge.net Wed May 7 11:24:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 03:24:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 13: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=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Wed May 7 11:37:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 03:37:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-733667 ] kwargs handled incorrectly Message-ID: Bugs item #733667, was opened at 2003-05-07 01:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Dalke (dalke) >Assigned to: Jeremy Hylton (jhylton) Summary: kwargs handled incorrectly Initial Comment: I'm using Python2.3 (first with a1 then tested with CVS version "Python 2.3b1+ (#7, May 6 2003, 23:41:12)" compiled a few minutes ago). There's a bug in how it handles an error condition with keyword arguments. Here's a reproducible Python 2.3b1+ (#7, May 6 2003, 23:41:12) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def add(a, b): ... print "add", repr(a), repr(b) ... return a + b ... >>> add(a=3) add 'a' 3 Traceback (most recent call last): File "", line 1, in ? File "", line 3, in add TypeError: cannot concatenate 'str' and 'int' objects >>> The expected behaviour is what Python 2.2 does, which is >>> def add(a, b): ... return a + b ... >>> add(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: add() takes exactly 2 non-keyword arguments (1 given) >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 05:37 Message: Logged In: YES user_id=80475 Jeremy, it looks like this bug was part of your patches on 2/5/2003. CVS runs the code the day before, but not on the day after. The culprit is likely in taking the fast_function() path which bypasses the usual keyword argument handling. See ceval.c 2.348 and the related changes to sysmodule.c and ceval.h. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 04:23 Message: Logged In: YES user_id=80475 def f(a,b): print a, b def g(a,b,**kw): print a, b, kw f(c=3) # prints c 3 g(c=3) # raises correct error for non-keyword arguments. So, the restated version of the problem is that: when keyword arguments are passed to a function not defining **kw, then the keyword in interpreted as a single for the first positional argument and the keyword value as the second positional argument. Weird and bad! Reverting to earlier versions of getargs.c did not help. Likewise the dict(red=3, blue=4) patch is not the culprit. The prime suspect is now the function call optimizations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 02:54 Message: Logged In: YES user_id=80475 Ouch! This is a bad one. Bumping up the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 From noreply@sourceforge.net Wed May 7 11:40:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 03:40:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-732783 ] test_grp failure on Mac OS X Message-ID: Bugs item #732783, was opened at 2003-05-05 18:31 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732783&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Walter Dörwald (doerwalter) Summary: test_grp failure on Mac OS X Initial Comment: I noticed that test_grp began failing for me on Mac OS X. I thought perhaps it was related to the changes Martin checked in for grpmodule.c Saturday (May 3rd) for OpenVMS, but a Python executable built on May 2nd also fails to pass the test. However, it passes using 2.2.2 (running against the 2.2.2 version of the test). % ./python.exe ../Lib/test/test_grp.py test_errors (__main__.GroupDatabaseTestCase) ... ok test_values (__main__.GroupDatabaseTestCase) ... FAIL =========================================== =========================== FAIL: test_values (__main__.GroupDatabaseTestCase) ----------------------------------------------------------- ----------- Traceback (most recent call last): File "../Lib/test/test_grp.py", line 46, in test_values self.assert_(max([self.valueseq(e2, x) \ File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError ----------------------------------------------------------- ----------- Ran 2 tests in 0.162s FAILED (failures=1) Traceback (most recent call last): File "../Lib/test/test_grp.py", line 103, in ? test_main() File "../Lib/test/test_grp.py", line 100, in test_main test_support.run_unittest(GroupDatabaseTestCase) File "/Users/skip/src/python/head/dist/src/Lib/test/ test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "/Users/skip/src/python/head/dist/src/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_grp.py", line 46, in test_values self.assert_(max([self.valueseq(e2, x) \ File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError I wonder if it's related to Walter's changes to test_grp.py on or about versions 1.14 or 1.15? Here's a session transcript which shows a couple problems. "ebygid" is a dict like entriesbygid in test_grp.py. "entries" is the output of grp.getgrall(). >>> pprint.pprint(ebygid) {-2: [('nobody', '*', -2, [])], -1: [('nogroup', '*', -1, [])], 0: [('wheel', '*', 0, ['skip'])], 1: [('daemon', '*', 1, ['root'])], 2: [('kmem', '*', 2, ['root'])], 3: [('sys', '*', 3, ['root'])], 4: [('tty', '*', 4, ['root'])], 5: [('operator', '*', 5, ['root'])], 6: [('mail', '*', 6, [])], 7: [('bin', '*', 7, [])], 20: [('staff', '*', 20, ['root'])], 25: [('smmsp', '*', 25, [])], 31: [('guest', '*', 31, ['root'])], 45: [('utmp', '*', 45, [])], 66: [('uucp', '*', 66, [])], 68: [('dialer', '*', 68, [])], 69: [('network', '*', 69, [])], 70: [('www', '*', 70, [])], 75: [('sshd', '*', 75, [])], 80: [('admin', '*', 80, ['root', 'skip'])], 99: [('unknown', '*', 99, [])], 250: [('news', '*', 250, [])], 251: [('mysql', '*', 251, [])], 252: [('pgsql', '*', 252, []), ('postgres', '*', 252, ['skip'])], 253: [('games', '*', 253, [])], 254: [('canna', '*', 254, [])], 255: [('postfix', '*', 255, [])], 256: [('maildrop', '*', 256, [])], 257: [('tomcat', '*', 257, [])], 258: [('jabber', '*', 258, [])], 259: [('opennms', '*', 259, [])], 260: [('clamav', '*', 260, [])]} >>> for e in entries: ... e2 = grp.getgrgid (e.gr_gid) ... print e2 ... print [veq(e2, x) for x in ebygid[e.gr_gid]] ... ('nobody', '', -2, []) [True] ('nogroup', '', -1, []) [True] ('wheel', '', 0, ['skip']) [True] ('daemon', '', 1, ['root']) [True] ('kmem', '', 2, ['root']) [True] ('sys', '', 3, ['root']) [True] ('tty', '', 4, ['root']) [True] ('operator', '', 5, ['root']) [True] ('mail', '', 6, []) [True] ('bin', '', 7, []) [True] ('staff', '', 20, ['root']) [True] ('guest', '', 31, ['root']) [True] ('utmp', '', 45, []) [True] ('uucp', '', 66, []) [True] ('dialer', '', 68, []) [True] ('network', '', 69, []) [True] ('www', '', 70, []) [True] ('admin', '', 80, ['root', 'skip']) [True] ('unknown', '', 99, []) [True] ('smmsp', '', 25, []) [True] ('mysql', '', 251, []) [True] ('sshd', '', 75, []) [True] ('news', '', 250, []) [True] ('pgsql', '', 252, ['skip']) [False, False] ('games', '', 253, []) [True] ('canna', '', 254, []) [True] ('postfix', '', 255, []) [True] ('maildrop', '', 256, []) [True] ('tomcat', '', 257, []) [True] ('jabber', '', 258, []) [True] ('opennms', '', 259, []) [True] ('clamav', '', 260, []) [True] ('pgsql', '', 252, ['skip']) [False, False] I think it arises from the fact that on my machine I have two group entries with the same id but different names (pgsql and postgres). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-07 12:40 Message: Logged In: YES user_id=89016 Did version 1.17 of test_grp.py fix this bug? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-05 21:47 Message: Logged In: YES user_id=89016 I think I have a fix for that (basically by removing the check whether a tuple similar to the one from pwd.getgrgid() is among those for the same gid returned by pwd.getgrall()). Unfortunately CVS says "Connection refused" today. I'll try again tomorrow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732783&group_id=5470 From noreply@sourceforge.net Wed May 7 12:12:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 04:12:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-732783 ] test_grp failure on Mac OS X Message-ID: Bugs item #732783, was opened at 2003-05-05 11:31 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732783&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Walter Dörwald (doerwalter) Summary: test_grp failure on Mac OS X Initial Comment: I noticed that test_grp began failing for me on Mac OS X. I thought perhaps it was related to the changes Martin checked in for grpmodule.c Saturday (May 3rd) for OpenVMS, but a Python executable built on May 2nd also fails to pass the test. However, it passes using 2.2.2 (running against the 2.2.2 version of the test). % ./python.exe ../Lib/test/test_grp.py test_errors (__main__.GroupDatabaseTestCase) ... ok test_values (__main__.GroupDatabaseTestCase) ... FAIL =========================================== =========================== FAIL: test_values (__main__.GroupDatabaseTestCase) ----------------------------------------------------------- ----------- Traceback (most recent call last): File "../Lib/test/test_grp.py", line 46, in test_values self.assert_(max([self.valueseq(e2, x) \ File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError ----------------------------------------------------------- ----------- Ran 2 tests in 0.162s FAILED (failures=1) Traceback (most recent call last): File "../Lib/test/test_grp.py", line 103, in ? test_main() File "../Lib/test/test_grp.py", line 100, in test_main test_support.run_unittest(GroupDatabaseTestCase) File "/Users/skip/src/python/head/dist/src/Lib/test/ test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "/Users/skip/src/python/head/dist/src/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_grp.py", line 46, in test_values self.assert_(max([self.valueseq(e2, x) \ File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError I wonder if it's related to Walter's changes to test_grp.py on or about versions 1.14 or 1.15? Here's a session transcript which shows a couple problems. "ebygid" is a dict like entriesbygid in test_grp.py. "entries" is the output of grp.getgrall(). >>> pprint.pprint(ebygid) {-2: [('nobody', '*', -2, [])], -1: [('nogroup', '*', -1, [])], 0: [('wheel', '*', 0, ['skip'])], 1: [('daemon', '*', 1, ['root'])], 2: [('kmem', '*', 2, ['root'])], 3: [('sys', '*', 3, ['root'])], 4: [('tty', '*', 4, ['root'])], 5: [('operator', '*', 5, ['root'])], 6: [('mail', '*', 6, [])], 7: [('bin', '*', 7, [])], 20: [('staff', '*', 20, ['root'])], 25: [('smmsp', '*', 25, [])], 31: [('guest', '*', 31, ['root'])], 45: [('utmp', '*', 45, [])], 66: [('uucp', '*', 66, [])], 68: [('dialer', '*', 68, [])], 69: [('network', '*', 69, [])], 70: [('www', '*', 70, [])], 75: [('sshd', '*', 75, [])], 80: [('admin', '*', 80, ['root', 'skip'])], 99: [('unknown', '*', 99, [])], 250: [('news', '*', 250, [])], 251: [('mysql', '*', 251, [])], 252: [('pgsql', '*', 252, []), ('postgres', '*', 252, ['skip'])], 253: [('games', '*', 253, [])], 254: [('canna', '*', 254, [])], 255: [('postfix', '*', 255, [])], 256: [('maildrop', '*', 256, [])], 257: [('tomcat', '*', 257, [])], 258: [('jabber', '*', 258, [])], 259: [('opennms', '*', 259, [])], 260: [('clamav', '*', 260, [])]} >>> for e in entries: ... e2 = grp.getgrgid (e.gr_gid) ... print e2 ... print [veq(e2, x) for x in ebygid[e.gr_gid]] ... ('nobody', '', -2, []) [True] ('nogroup', '', -1, []) [True] ('wheel', '', 0, ['skip']) [True] ('daemon', '', 1, ['root']) [True] ('kmem', '', 2, ['root']) [True] ('sys', '', 3, ['root']) [True] ('tty', '', 4, ['root']) [True] ('operator', '', 5, ['root']) [True] ('mail', '', 6, []) [True] ('bin', '', 7, []) [True] ('staff', '', 20, ['root']) [True] ('guest', '', 31, ['root']) [True] ('utmp', '', 45, []) [True] ('uucp', '', 66, []) [True] ('dialer', '', 68, []) [True] ('network', '', 69, []) [True] ('www', '', 70, []) [True] ('admin', '', 80, ['root', 'skip']) [True] ('unknown', '', 99, []) [True] ('smmsp', '', 25, []) [True] ('mysql', '', 251, []) [True] ('sshd', '', 75, []) [True] ('news', '', 250, []) [True] ('pgsql', '', 252, ['skip']) [False, False] ('games', '', 253, []) [True] ('canna', '', 254, []) [True] ('postfix', '', 255, []) [True] ('maildrop', '', 256, []) [True] ('tomcat', '', 257, []) [True] ('jabber', '', 258, []) [True] ('opennms', '', 259, []) [True] ('clamav', '', 260, []) [True] ('pgsql', '', 252, ['skip']) [False, False] I think it arises from the fact that on my machine I have two group entries with the same id but different names (pgsql and postgres). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-07 06:12 Message: Logged In: YES user_id=44345 Yes, my apologies for not responding sooner. Closing... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-07 05:40 Message: Logged In: YES user_id=89016 Did version 1.17 of test_grp.py fix this bug? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-05 14:47 Message: Logged In: YES user_id=89016 I think I have a fix for that (basically by removing the check whether a tuple similar to the one from pwd.getgrgid() is among those for the same gid returned by pwd.getgrall()). Unfortunately CVS says "Connection refused" today. I'll try again tomorrow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732783&group_id=5470 From noreply@sourceforge.net Wed May 7 12:53:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 04:53:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-733819 ] PackMan recursive/force fails on pseudo packages Message-ID: Bugs item #733819, was opened at 2003-05-07 13:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733819&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 recursive/force fails on pseudo packages Initial Comment: If you set both install dependencies and overwrite, and the package depends on a pseudo-package, PackMan tries to install that pseudo- package and fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733819&group_id=5470 From noreply@sourceforge.net Wed May 7 13:04:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 05:04:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-731631 ] OSX installer .pkg file permissions Message-ID: Bugs item #731631, was opened at 2003-05-03 00:34 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: OSX installer .pkg file permissions Initial Comment: The files installed by the OSX installer .pkg should be group writable. This goes both for the files installed in /Library/Frameworks/ Python.framework and /Applications/MacPython-2.3 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-07 14:04 Message: Logged In: YES user_id=45365 This turns out to be non-trivial: the installed Python tree that is used to create the installer has group-write turned off, that's the way Python always installs the tree. I could do a recursive chmod g+w before creating the installer, what do you think, would that be safe? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470 From noreply@sourceforge.net Wed May 7 13:17:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 05:17:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-697990 ] Document strptime limitation Message-ID: Bugs item #697990, was opened at 2003-03-05 13:48 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 Category: Documentation Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Brett Cannon (bcannon) Summary: Document strptime limitation Initial Comment: Python Library Reference, Chapter 6.9: strptime: Many (at least glibc 2) versions of strptime can't parse the time zone (which strftime prints with %Z). This should be mentioned as a warning in the documentation. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-05-07 13:17 Message: Logged In: YES user_id=6656 Is 2.3 going to call the libc strptime? If we keep using Brett's, presumably this is irrelevant. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-07 01:37 Message: Logged In: YES user_id=357491 I will add some note, but I don't know what yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 From noreply@sourceforge.net Wed May 7 15:21:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 07:21:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-07 15:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 21:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 01:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 18:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 09:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 16:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 16:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 21:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 21:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 21:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 20:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Wed May 7 15:43:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 07:43:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-733667 ] kwargs handled incorrectly Message-ID: Bugs item #733667, was opened at 2003-05-07 01:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Dalke (dalke) Assigned to: Jeremy Hylton (jhylton) Summary: kwargs handled incorrectly Initial Comment: I'm using Python2.3 (first with a1 then tested with CVS version "Python 2.3b1+ (#7, May 6 2003, 23:41:12)" compiled a few minutes ago). There's a bug in how it handles an error condition with keyword arguments. Here's a reproducible Python 2.3b1+ (#7, May 6 2003, 23:41:12) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def add(a, b): ... print "add", repr(a), repr(b) ... return a + b ... >>> add(a=3) add 'a' 3 Traceback (most recent call last): File "", line 1, in ? File "", line 3, in add TypeError: cannot concatenate 'str' and 'int' objects >>> The expected behaviour is what Python 2.2 does, which is >>> def add(a, b): ... return a + b ... >>> add(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: add() takes exactly 2 non-keyword arguments (1 given) >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 09:42 Message: Logged In: YES user_id=80475 Attaching a patch (actually a band-aid temporary fix). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 05:37 Message: Logged In: YES user_id=80475 Jeremy, it looks like this bug was part of your patches on 2/5/2003. CVS runs the code the day before, but not on the day after. The culprit is likely in taking the fast_function() path which bypasses the usual keyword argument handling. See ceval.c 2.348 and the related changes to sysmodule.c and ceval.h. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 04:23 Message: Logged In: YES user_id=80475 def f(a,b): print a, b def g(a,b,**kw): print a, b, kw f(c=3) # prints c 3 g(c=3) # raises correct error for non-keyword arguments. So, the restated version of the problem is that: when keyword arguments are passed to a function not defining **kw, then the keyword in interpreted as a single for the first positional argument and the keyword value as the second positional argument. Weird and bad! Reverting to earlier versions of getargs.c did not help. Likewise the dict(red=3, blue=4) patch is not the culprit. The prime suspect is now the function call optimizations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 02:54 Message: Logged In: YES user_id=80475 Ouch! This is a bad one. Bumping up the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 From noreply@sourceforge.net Wed May 7 17:57:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 09:57:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-733769 ] test_logging hangs on old RH Linux Message-ID: Bugs item #733769, was opened at 2003-05-07 06:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733769&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging hangs on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. test_logging hangs after -- log_test3 end --------------------------------------------------- i.e., during the new fancier code for shutting down the tcp server in the finally block at the end of main(). When I run the old test_logging.py from the 2.3a2 distribution using the Python I built from 2.3b1, everything is fine. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 12:57 Message: Logged In: YES user_id=33168 test_logging.py was fixed after the beta was released. Can you try the current version from CVS? You only need the one file Lib/test/test_logging.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733769&group_id=5470 From noreply@sourceforge.net Wed May 7 18:47:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 10:47:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-733769 ] test_logging hangs on old RH Linux Message-ID: Bugs item #733769, was opened at 2003-05-07 13:03 Message generated for change (Comment added) made by llxyitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733769&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging hangs on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. test_logging hangs after -- log_test3 end --------------------------------------------------- i.e., during the new fancier code for shutting down the tcp server in the finally block at the end of main(). When I run the old test_logging.py from the 2.3a2 distribution using the Python I built from 2.3b1, everything is fine. ---------------------------------------------------------------------- >Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 20:47 Message: Logged In: YES user_id=773482 OK. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 19:57 Message: Logged In: YES user_id=33168 test_logging.py was fixed after the beta was released. Can you try the current version from CVS? You only need the one file Lib/test/test_logging.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733769&group_id=5470 From noreply@sourceforge.net Wed May 7 19:07:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 11:07:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 13:24 Message generated for change (Comment added) made by llxyitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- >Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Wed May 7 19:14:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 11:14:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 13:24 Message generated for change (Comment added) made by llxyitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- >Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:14 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Wed May 7 19:29:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 11:29:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-727732 ] getpath.c-generated prefix wrong for Tru64 scripts Message-ID: Bugs item #727732, was opened at 2003-04-25 14:57 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727732&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: getpath.c-generated prefix wrong for Tru64 scripts Initial Comment: Under Tru64 (version 5.1a, and probably others), when a Python script is structured like so: #!/something/bin/python import sys print sys.prefix the calculation of prefix in getpath.c won't work correctly. The reason is that argv[0] will be 'python' rather than '/something/bin/python' (as it would be under, say, Linux). The code happens to work correctly in some simple scenarios, but fails in a pretty mysterious way if one has a different python in one's PATH than the one in the #! line. So, for example, if my PATH=/usr/bin and there is a /usr/bin/python, then if I run the script above, sys.prefix will be set to '/usr' instead of '/something' and the wrong module path will be set up, etc. It would be much better to simply obey the compiled PREFIX instead, at least in the case where argv[0] has no slashes. ---------------------------------------------------------------------- >Comment By: Mike Coleman (mkc) Date: 2003-05-07 13:29 Message: Logged In: YES user_id=555 I hunted around in the man pages and googled and I couldn't find much. There is a proc ioctl PIOCOPENM (see http://www.advogato.org/person/jum/diary.html?start=34) which will give you an fd to the executable, but I don't know of any way to map that back to a filename. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 07:43 Message: Logged In: YES user_id=21627 Is there any way for a binary to find out its location on disk, on Tru64? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727732&group_id=5470 From noreply@sourceforge.net Wed May 7 19:42:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 11:42:15 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-734115 ] Packaging without disturbing an existing installation Message-ID: Feature Requests item #734115, was opened at 2003-05-07 11:42 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=734115&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Mansfield (stmansfield) Assigned to: Nobody/Anonymous (nobody) Summary: Packaging without disturbing an existing installation Initial Comment: As a developer/maintainer of a custom embedded GNU/Linux distribution, I need to be able to build and package various components that make up this operating system in as convenient, painless manner possible. One thing that is missing from the Python build process is the ability to specify an alternate destination directory for packaging concerns. To that end, at the request of one of the 'python-help' volunteers (thanks Matt!) I am submitting this feature request and patch. This patch will modify the 'Makefile.pre.in' file, prepending a DESTDIR in front installation target directories. Note that this is pretty much de-facto standard behavior for most autoconf- automake- type builds. This will not alter the 'prefix', 'execprefix' or other directories that hinge on same. Once this patch is applied and the sources are successfully built, one could do a "make DESTDIR='/opt/pkg' install" and have the installtion faithfully reproduced under '/opt/pkg' (example directory only), and create a finished, deployable package; saving one from having to suffer the pain of having to pick through /usr, and also saving the pain of potentially over-writing whatever existing installation might exist on the build machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=734115&group_id=5470 From noreply@sourceforge.net Wed May 7 20:27:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 12:27:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-734149 ] tempfile module broken in 2.3 Message-ID: Bugs item #734149, was opened at 2003-05-07 12: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=734149&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile module broken in 2.3 Initial Comment: Thiserror persists since 2.3alpha >>> import tempfile Traceback (most recent call last): File "", line 1, in ? File "/roseland0/cdat/latest/lib/python2.3/tempfile.py", line 33, in ? from random import Random as _Random File "/roseland0/cdat/latest/lib/python2.3/random.py", line 61, in ? import _random ImportError: No module named _random ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 From noreply@sourceforge.net Wed May 7 21:02:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 13:02:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-734170 ] PyArg_ParseTuple("u") inconstency Message-ID: Bugs item #734170, was opened at 2003-05-07 22:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734170&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: M.-A. Lemburg (lemburg) Summary: PyArg_ParseTuple("u") inconstency Initial Comment: PyArg_ParseTuple behaves strangly with the format character "u" when a plain string is passed as the argument. This seems to perform the conversion value.decoded("utf-16"), which is very surprising and inconsistent with the behaviour of the python expression unicode(value) with is equivalent with value.decode("ascii"). The current behaviour will confuse users that pass plain strings to extension functions expecting unicode arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734170&group_id=5470 From noreply@sourceforge.net Wed May 7 21:37:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 13:37:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-734170 ] PyArg_ParseTuple("u") inconstency Message-ID: Bugs item #734170, was opened at 2003-05-07 22:02 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734170&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: M.-A. Lemburg (lemburg) Summary: PyArg_ParseTuple("u") inconstency Initial Comment: PyArg_ParseTuple behaves strangly with the format character "u" when a plain string is passed as the argument. This seems to perform the conversion value.decoded("utf-16"), which is very surprising and inconsistent with the behaviour of the python expression unicode(value) with is equivalent with value.decode("ascii"). The current behaviour will confuse users that pass plain strings to extension functions expecting unicode arguments. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-05-07 22:37 Message: Logged In: YES user_id=38388 Why is the current beahviour surprising ? The "u" parser marker reads a buffer like object and interprets it as Py_UNICODE array. It is very different from what unicode(value) does. The "es" marker takes care of unicode(value, encoding) kind of conversions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734170&group_id=5470 From noreply@sourceforge.net Wed May 7 21:45:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 13:45:49 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py Message-ID: Feature Requests item #494854, was opened at 2001-12-19 02:16 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: add platform.py Initial Comment: Here's a request to add Marc-Andre Lemburg's platform.py to the Python standard library. It provides more complete platform information than either sys.platform or distutils.util.get_platform() For more info, see: http://www.lemburg.com/files/python/platform.py ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 02:42 Message: Logged In: YES user_id=6380 OK, I have no problem with this. MAL, can you check it in yourself? Maybe you can remove the history from the docstring? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-04-24 01:06 Message: Logged In: YES user_id=85984 I'm assigning this to Guido, so it can be looked at before 2.3b1 is released. This issue seems like a no brainer to me, yet it has been open for almost 3 years now. I'd really like to be able to use platform.py in Python 2.3. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-04-02 02:37 Message: Logged In: YES user_id=85984 How about adding platform.py to the distribution even if there is no docs forthcoming? It's not like this would be the first undocumented module. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-29 16:14 Message: Logged In: YES user_id=21627 Is there any hope of getting documentation? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-05 17:51 Message: Logged In: YES user_id=38388 Guido has already approved the addition; so it's basically just the docs that are currently missing... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-19 10:27 Message: Logged In: YES user_id=38388 No problem from here :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470 From noreply@sourceforge.net Wed May 7 22:31:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 14:31:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-697990 ] Document strptime limitation Message-ID: Bugs item #697990, was opened at 2003-03-05 05:48 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Brett Cannon (bcannon) Summary: Document strptime limitation Initial Comment: Python Library Reference, Chapter 6.9: strptime: Many (at least glibc 2) versions of strptime can't parse the time zone (which strftime prints with %Z). This should be mentioned as a warning in the documentation. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-07 14:31 Message: Logged In: YES user_id=357491 So, from what I remember when Guido switched off the libc usage to get more testing of _strptime Tim was in support of just moving completely over to _strptime while Guido seemed okay with it. There was no final declaration that I know of (if there was then it was rather silly to leave in the libc wrapper code). If _strptime does turn into the only implementation I will completely flesh out the docs on _strptime and its limitations (this is one of them; been debating whether it should be able to recognize UTC and GMT as timezones beyond the two the platforms tends to know). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-07 05:17 Message: Logged In: YES user_id=6656 Is 2.3 going to call the libc strptime? If we keep using Brett's, presumably this is irrelevant. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 17:37 Message: Logged In: YES user_id=357491 I will add some note, but I don't know what yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 From noreply@sourceforge.net Thu May 8 00:14:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 16:14:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-731631 ] OSX installer .pkg file permissions Message-ID: Bugs item #731631, was opened at 2003-05-03 00:34 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: OSX installer .pkg file permissions Initial Comment: The files installed by the OSX installer .pkg should be group writable. This goes both for the files installed in /Library/Frameworks/ Python.framework and /Applications/MacPython-2.3 ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-08 01:14 Message: Logged In: YES user_id=92689 Maybe my diagnosis is off. When I install (a non-framework) Python from the source, I don't use sudo, I just do "make install". In that case all files are owned by me. The installer however installs everything as root, and with the files being not group writable it means that I (even as an admin) can't move/ overwrite/delete the files without using sudo or changing the permissions. I would expect to be able to have write permissions to the installed files if I'm an admin user. Don't know how to fix that easily, either. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-07 14:04 Message: Logged In: YES user_id=45365 This turns out to be non-trivial: the installed Python tree that is used to create the installer has group-write turned off, that's the way Python always installs the tree. I could do a recursive chmod g+w before creating the installer, what do you think, would that be safe? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731631&group_id=5470 From noreply@sourceforge.net Thu May 8 00:29:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 16:29:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-487471 ] urllib2 proxyhandle won't work. Message-ID: Bugs item #487471, was opened at 2001-11-30 12:54 Message generated for change (Comment added) made by micahs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ha Shao (hashao) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 proxyhandle won't work. Initial Comment: For python 2.2b2: Adding proxyhandler with build_opener, install_opener does not work since order of the handlers does matter (my guess). In the current code, new handlers are appended at the end of the handlers list. At least under windows, the proxyhandle will never got called if it is added with install_opener. HTTPHandler always get called before proxyhandler if the default list is altered. The attached patch try to reserve the order of handlers based on their baseclass when adding new handlers. Handlers with the same baseclasses might be added more than once. Not sure if it is a good thing or bad thing. Current code will raise except when it trys to remove the default handlers twice. Since order does matter, build_opener should be repleased by a list like class such that user can insert their handlers to specific place. ---------------------------------------------------------------------- Comment By: Micah Stetson (micahs) Date: 2003-05-07 23:29 Message: Logged In: YES user_id=774014 I don't know about Ha Shao, but I have the problem with Python 2.2.2. My work around was to modify urllib2.build_opener to add the user's supplied handlers before the defaults. Shao's idea of a list-like class is probably better. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 21:50 Message: Logged In: YES user_id=33168 Ha Shao, I know there were many changes in Python 2.2.x in this area. Do you still have this problem? Can this bug be closed? ---------------------------------------------------------------------- Comment By: Ha Shao (hashao) Date: 2001-11-30 13:10 Message: Logged In: YES user_id=8717 forgot some code and changed a stupid variable name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 From noreply@sourceforge.net Thu May 8 02:20:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 18:20:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-734149 ] tempfile module broken in 2.3 Message-ID: Bugs item #734149, was opened at 2003-05-07 15:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 >Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile module broken in 2.3 Initial Comment: Thiserror persists since 2.3alpha >>> import tempfile Traceback (most recent call last): File "", line 1, in ? File "/roseland0/cdat/latest/lib/python2.3/tempfile.py", line 33, in ? from random import Random as _Random File "/roseland0/cdat/latest/lib/python2.3/random.py", line 61, in ? import _random ImportError: No module named _random ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 21:20 Message: Logged In: YES user_id=33168 This is a build problem. Why doesn't Modules/_randommodule.c get built? What operating system and version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 From noreply@sourceforge.net Thu May 8 04:31:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 20:31:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-727719 ] email parsedate still wrong (PATCH) Message-ID: Bugs item #727719, was opened at 2003-04-25 15:40 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727719&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bob Miller (kbob) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email parsedate still wrong (PATCH) Initial Comment: Under python2.3a2 and current CVS, this script: #!/usr/bin/python2.3 import email.Utils d = '25 Feb 2003 13:47:26 -0800' print email.Utils.parsedate_tz(d) prints 'None'. It should print a tuple. Here is a patch to the bug, which was apparently introduced by _parseaddr.py rev 1.5. tivopc ~ mips> diff -u _parseaddr.py~ _parseaddr.py --- _parseaddr.py~ Fri Apr 18 19:21:10 2003 +++ _parseaddr.py Fri Apr 18 19:23:08 2003 @@ -1,4 +1,4 @@ -# Copyright (C) 2002 Python Software Foundation +# Copyright (C) 2002, 2003 Python Software Foundation """Email address parsing code. @@ -54,9 +54,9 @@ del data[0] else: i = data[0].rfind(',') - if i < 0: - return None - data[0] = data[0][i+1:] + if i >= 0: + # Trim off the leading dayname. + data[0] = data[0][i+1:] if len(data) == 3: # RFC 850 date, deprecated stuff = data[0].split('-') if len(stuff) == 3: ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-07 23:31 Message: Logged In: YES user_id=12800 Thanks Bob. I like Dan Berlin's patch in SF bug # 732761 better because it doesn't cause regressions in the test suite. I'm applying that patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727719&group_id=5470 From noreply@sourceforge.net Thu May 8 04:32:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 07 May 2003 20:32:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-732761 ] 2.3 breaks email date parsing Message-ID: Bugs item #732761, was opened at 2003-05-05 11:56 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732761&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Daniel Berlin (dberlin) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: 2.3 breaks email date parsing Initial Comment: Parsing dates in emails is broken in 2.3 compared to 2.2.2. Changing parsedate_tz back to what it was in 2.2.2 fixes it. I'm not sure who or why this change was made, but it clearly doesn't handle cases it used to: (oldparseaddr is the 2.3 version with the patch at the bottom applied, which reverts it to what it was in 2.2.2) >>> import _parseaddr >>> _parseaddr.parsedate_tz("3 Mar 2001 02:04:50 -0000") >>> import oldparseaddr >>> oldparseaddr.parsedate_tz("3 Mar 2001 02:04:50 -0000") (2001, 3, 3, 2, 4, 50, 0, 0, 0, 0) >>> The problem is obvious from looking at the new code: The old version would only care if it actually found something it needed to delete. The new version assumes there *must* be a comma in the date if there is no dayname, and if there isn't, returns nothing. I wanted to know if this was a mistake, or done on purpose. If it's a mistake, i'll submit a patch to sourceforge to fix it. Index: _parseaddr.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/email/_parseaddr.py,v retrieving revision 1.5 diff -u -3 -p -r1.5 _parseaddr.py --- _parseaddr.py 17 Mar 2003 18:35:42 -0000 1.5 +++ _parseaddr.py 2 May 2003 15:42:30 -0000 @@ -49,14 +49,9 @@ def parsedate_tz(data): data = data.split() # The FWS after the comma after the day-of-week is optional, so search and # adjust for this. - if data[0].endswith(',') or data[0].lower() in _daynames: + if data[0][-1] in (',', '.') or data[0].lower() in _daynames: # There's a dayname here. Skip it del data[0] - else: - i = data[0].rfind(',') - if i < 0: - return None - data[0] = data[0][i+1:] if len(data) == 3: # RFC 850 date, deprecated stuff = data[0].split('-') if len(stuff) == 3: ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-07 23:32 Message: Logged In: YES user_id=12800 Thanks Daniel, your second patch is exactly right. I'm applying this to CVS and backporting to Python 2.2.3. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-05-07 06:21 Message: Logged In: YES user_id=75166 The following patch solves the problem and is tolerant of slightly malformed dates with a dayname which is not properly delimted by white space. diff -u -r -P email/_parseaddr.py email-tzp/_parseaddr.py --- email/_parseaddr.py 2003-03-30 21:21:28.000000000 +0100 +++ email-tzp/_parseaddr.py 2003-05-06 21:56:37.000000000 +0100 @@ -54,9 +54,9 @@ del data[0] else: i = data[0].rfind(',') - if i < 0: - return None - data[0] = data[0][i+1:] + if i >= 0: + # There's what may be a dayname here. Skip it + data[0] = data[0][i+1:] if len(data) == 3: # RFC 850 date, deprecated stuff = data[0].split('-') if len(stuff) == 3: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732761&group_id=5470 From noreply@sourceforge.net Thu May 8 08:03:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 00:03:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 13:24 Message generated for change (Comment added) made by llxyitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- >Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 10:03 Message: Logged In: YES user_id=773482 I did a little historical research on this machine. It seems to have been a vanilla Red Hat 6.1 install. So I think we're going to want to support this. I worked around the problem by manually commenting out those two symbols in fcntmodule.c. I think configure needs to detect this problem and do that automatically. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:14 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Thu May 8 09:30:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 01:30:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 13:24 Message generated for change (Comment added) made by llxyitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- >Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 11:30 Message: Logged In: YES user_id=773482 I checked a clean copy of glib-2.1.2 from gnu.org - it indeed is missing those two symbols. Here is how to fix this bug: 1. To configure.in add the line: AC_CHECK_DECLS([I_GWROPT, I_GETCLTIME],,,[#include ]) 2. In fcntlmodule.c, surround each of the two lines that use these symbols with an #if, like so: #if defined(HAVE_DECL_I_GWROPT) && HAVE_DECL_I_GWROPT ... #endif ... #if defined(HAVE_DECL_I_GETCLTIME) && HAVE_DECL_I_GETCLTIME ... #endif ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 10:03 Message: Logged In: YES user_id=773482 I did a little historical research on this machine. It seems to have been a vanilla Red Hat 6.1 install. So I think we're going to want to support this. I worked around the problem by manually commenting out those two symbols in fcntmodule.c. I think configure needs to detect this problem and do that automatically. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:14 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Thu May 8 12:38:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 04:38:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 11:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-05-08 12:38 Message: Logged In: YES user_id=6656 I think the attached patch is all that is required. Can you try it? ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 09:30 Message: Logged In: YES user_id=773482 I checked a clean copy of glib-2.1.2 from gnu.org - it indeed is missing those two symbols. Here is how to fix this bug: 1. To configure.in add the line: AC_CHECK_DECLS([I_GWROPT, I_GETCLTIME],,,[#include ]) 2. In fcntlmodule.c, surround each of the two lines that use these symbols with an #if, like so: #if defined(HAVE_DECL_I_GWROPT) && HAVE_DECL_I_GWROPT ... #endif ... #if defined(HAVE_DECL_I_GETCLTIME) && HAVE_DECL_I_GETCLTIME ... #endif ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 08:03 Message: Logged In: YES user_id=773482 I did a little historical research on this machine. It seems to have been a vanilla Red Hat 6.1 install. So I think we're going to want to support this. I worked around the problem by manually commenting out those two symbols in fcntmodule.c. I think configure needs to detect this problem and do that automatically. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 19:14 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 19:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Thu May 8 14:19:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 06:19:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 13:24 Message generated for change (Comment added) made by llxyitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- >Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 16:19 Message: Logged In: YES user_id=773482 Yep, works for me. It sure is simpler. Only thing is - do you know 100% that for every stropts.h out there, and for every one that will arise in the future, these are #defines and not actual symbols? If so, then use it (and someone should QA that on all platforms). If not - those symbols will silently vanish on some platform someday and go figure out why. Even if so, in light of PEP 11 I would at least add a comment at the appropriate point in configure.in. The comment should mention Red Hat 6.1 and glibc-2.1.2. That way, when this platform gets de-supported someday, people will be able to clean up our mess. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-08 14:38 Message: Logged In: YES user_id=6656 I think the attached patch is all that is required. Can you try it? ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 11:30 Message: Logged In: YES user_id=773482 I checked a clean copy of glib-2.1.2 from gnu.org - it indeed is missing those two symbols. Here is how to fix this bug: 1. To configure.in add the line: AC_CHECK_DECLS([I_GWROPT, I_GETCLTIME],,,[#include ]) 2. In fcntlmodule.c, surround each of the two lines that use these symbols with an #if, like so: #if defined(HAVE_DECL_I_GWROPT) && HAVE_DECL_I_GWROPT ... #endif ... #if defined(HAVE_DECL_I_GETCLTIME) && HAVE_DECL_I_GETCLTIME ... #endif ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 10:03 Message: Logged In: YES user_id=773482 I did a little historical research on this machine. It seems to have been a vanilla Red Hat 6.1 install. So I think we're going to want to support this. I worked around the problem by manually commenting out those two symbols in fcntmodule.c. I think configure needs to detect this problem and do that automatically. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:14 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Thu May 8 16:15:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 08:15:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-734695 ] Function for creating/extracting CoreFoundation types Message-ID: Bugs item #734695, was opened at 2003-05-08 17:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Function for creating/extracting CoreFoundation types Initial Comment: pymactoolbox.h contains a number of functions for converting from CoreFoundation references to Python wrappers for those functions (e.g. CFTypeRefObj_New). Simularly there are functions for extracting the CoreFoundation reference from a wrapped Python object (e.g. CFTypeRefObj_Convert). It would be nice if CFTypeRefObj_New would automaticly create a more specialized Python wrapper if you pass it a CFArrayRef, this decreases the coupling between the python core and 3th party extension modules. Simularly CFTypeRefObj_Convert should "work" when passed a CFArrayRefObj. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 From noreply@sourceforge.net Thu May 8 16:28:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 08:28:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-734170 ] PyArg_ParseTuple("u") inconstency Message-ID: Bugs item #734170, was opened at 2003-05-07 22:02 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734170&group_id=5470 Category: Unicode Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: M.-A. Lemburg (lemburg) Summary: PyArg_ParseTuple("u") inconstency Initial Comment: PyArg_ParseTuple behaves strangly with the format character "u" when a plain string is passed as the argument. This seems to perform the conversion value.decoded("utf-16"), which is very surprising and inconsistent with the behaviour of the python expression unicode(value) with is equivalent with value.decode("ascii"). The current behaviour will confuse users that pass plain strings to extension functions expecting unicode arguments. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-05-08 17:28 Message: Logged In: YES user_id=580910 The conversion for plain is not mentioned in the the documentation (section 5.5 of the in-development documentation at python.org). Based on that documentation I'd assume that plain strings will either not be accepted or be converted to unicode objects. As a user of functions that use the 'u' format specifier I was very surprised when my plain string argument seemingly got mangled. Only after close checking I noticed that the string is interpreted as raw utf-16 data. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-05-07 22:37 Message: Logged In: YES user_id=38388 Why is the current beahviour surprising ? The "u" parser marker reads a buffer like object and interprets it as Py_UNICODE array. It is very different from what unicode(value) does. The "es" marker takes care of unicode(value, encoding) kind of conversions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734170&group_id=5470 From noreply@sourceforge.net Thu May 8 17:13:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 09:13:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-734149 ] tempfile module broken in 2.3 Message-ID: Bugs item #734149, was opened at 2003-05-07 14:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile module broken in 2.3 Initial Comment: Thiserror persists since 2.3alpha >>> import tempfile Traceback (most recent call last): File "", line 1, in ? File "/roseland0/cdat/latest/lib/python2.3/tempfile.py", line 33, in ? from random import Random as _Random File "/roseland0/cdat/latest/lib/python2.3/random.py", line 61, in ? import _random ImportError: No module named _random ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-08 11:13 Message: Logged In: YES user_id=80475 Also, verify that your setup.py has a line like: exts.append( Extension("_random", ["_randommodule.c"]) ) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 20:20 Message: Logged In: YES user_id=33168 This is a build problem. Why doesn't Modules/_randommodule.c get built? What operating system and version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 From noreply@sourceforge.net Thu May 8 17:22:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 09:22:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-696777 ] How to make a class iterable using a member generator. Message-ID: Bugs item #696777, was opened at 2003-03-03 14:17 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696777&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) >Assigned to: Raymond Hettinger (rhettinger) Summary: How to make a class iterable using a member generator. Initial Comment: This should probably go at the end of 2.2.5 (LibRef). [I was trying all possible variations of __iter__ returning self, with next() as a method...] """If you are designing a class that should be iterable, i.e. you want to be able to say "for x in myClass:...", and, you also want the convenience of using a member function that is a generator to provide the items, your class' __iter__() method should return "self.myGenerator (self)". The object returned from this call is an iterator- generator that implements both of the required __iter__() and next() methods. Example: class Range10: def __init__(self): self.scale = 5 def __iter__(self): return Range10.generateItems(self) def generateItems(self): for i in range(10): yield i * self.scale There are a couple of subtleties here. First, only "user- defined functions" are converted to methods when accessed through a class or instance, i.e.myObject.foo () will extract the foo function wrap it up as a method object, insert myObject in the argument list and call it (LibRef: 3.2/Callable types/User-defined methods). [thanks to Alex M. for clarifying this issue for me] This automatic conversion does not happen for any other type of objects defined inside class scope. In our case, generateItems() will be a generator-iterator, i.e. not a "user-defined function". Thus the conversion to an instance method does not happen, and it is left as a static method of the class. [this seems like it might be a bug to me...]. To get around this irregularity, make sure your __iter__() calls generateItems() as a static method, and explictly passes self. """ -- bjorn ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-03-09 12:57 Message: Logged In: YES user_id=593130 As others have posted (with examples) on both c.l.py and py-dev, it is both possible and simpler to write __init__ itself as a generator function, thereby returning a generator-iterator object with the requisite __init_() and next() methods.. Since this does not seem to be obvious to many people, I would agree that *this* should be mentioned in the docs. All the rest of the discussion about access and static methods is irrelevant for this purpose. >>> from __future__ import generators >>> class Range10: ... def __init__(self,scale): ... self.scale = scale ... def __iter__(self): ... scale = self.scale ... for i in range(10): yield i * scale ... >>> for i in Range10(4): ... print i ... 0 4 8 12 16 20 24 28 32 36 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696777&group_id=5470 From noreply@sourceforge.net Thu May 8 19:02:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 11:02:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-734149 ] tempfile module broken in 2.3 Message-ID: Bugs item #734149, was opened at 2003-05-07 12:27 Message generated for change (Comment added) made by cdoutri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile module broken in 2.3 Initial Comment: Thiserror persists since 2.3alpha >>> import tempfile Traceback (most recent call last): File "", line 1, in ? File "/roseland0/cdat/latest/lib/python2.3/tempfile.py", line 33, in ? from random import Random as _Random File "/roseland0/cdat/latest/lib/python2.3/random.py", line 61, in ? import _random ImportError: No module named _random ---------------------------------------------------------------------- >Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 11:02 Message: Logged In: YES user_id=78442 Sorry, I forgot to specify, I'm using the "default" setup.py on Linux box, it fails on both RH8.0 and RH9.0 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-08 09:13 Message: Logged In: YES user_id=80475 Also, verify that your setup.py has a line like: exts.append( Extension("_random", ["_randommodule.c"]) ) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 18:20 Message: Logged In: YES user_id=33168 This is a build problem. Why doesn't Modules/_randommodule.c get built? What operating system and version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 From noreply@sourceforge.net Thu May 8 19:27:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 11:27:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-734806 ] telnetlib.read_until: float req'd for timeout Message-ID: Bugs item #734806, was opened at 2003-05-08 14: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=734806&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Craig Allen (cba037) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.read_until: float req'd for timeout Initial Comment: The read_until (and I assume expect) method(s) have an optional timeout parameter; a float is required but this is not documented; use of an integer causes an exception. Documentation needs to mention the need for a float value (alternatively, telnetlib should convert to a float). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734806&group_id=5470 From noreply@sourceforge.net Thu May 8 19:47:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 11:47:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-734149 ] tempfile module broken in 2.3 Message-ID: Bugs item #734149, was opened at 2003-05-07 12:27 Message generated for change (Comment added) made by cdoutri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 Category: Build Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile module broken in 2.3 Initial Comment: Thiserror persists since 2.3alpha >>> import tempfile Traceback (most recent call last): File "", line 1, in ? File "/roseland0/cdat/latest/lib/python2.3/tempfile.py", line 33, in ? from random import Random as _Random File "/roseland0/cdat/latest/lib/python2.3/random.py", line 61, in ? import _random ImportError: No module named _random ---------------------------------------------------------------------- >Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 11:47 Message: Logged In: YES user_id=78442 Sorry, I was somewhat overwritting setup.py with one from 2.2.... My mistake ---------------------------------------------------------------------- Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 11:02 Message: Logged In: YES user_id=78442 Sorry, I forgot to specify, I'm using the "default" setup.py on Linux box, it fails on both RH8.0 and RH9.0 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-08 09:13 Message: Logged In: YES user_id=80475 Also, verify that your setup.py has a line like: exts.append( Extension("_random", ["_randommodule.c"]) ) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 18:20 Message: Logged In: YES user_id=33168 This is a build problem. Why doesn't Modules/_randommodule.c get built? What operating system and version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 From noreply@sourceforge.net Thu May 8 20:04:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 12:04:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-734149 ] tempfile module broken in 2.3 Message-ID: Bugs item #734149, was opened at 2003-05-07 15:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 Category: Build >Group: Not a Bug Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile module broken in 2.3 Initial Comment: Thiserror persists since 2.3alpha >>> import tempfile Traceback (most recent call last): File "", line 1, in ? File "/roseland0/cdat/latest/lib/python2.3/tempfile.py", line 33, in ? from random import Random as _Random File "/roseland0/cdat/latest/lib/python2.3/random.py", line 61, in ? import _random ImportError: No module named _random ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-08 15:04 Message: Logged In: YES user_id=31435 That's OK. Just don't do it again . ---------------------------------------------------------------------- Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 14:47 Message: Logged In: YES user_id=78442 Sorry, I was somewhat overwritting setup.py with one from 2.2.... My mistake ---------------------------------------------------------------------- Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 14:02 Message: Logged In: YES user_id=78442 Sorry, I forgot to specify, I'm using the "default" setup.py on Linux box, it fails on both RH8.0 and RH9.0 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-08 12:13 Message: Logged In: YES user_id=80475 Also, verify that your setup.py has a line like: exts.append( Extension("_random", ["_randommodule.c"]) ) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 21:20 Message: Logged In: YES user_id=33168 This is a build problem. Why doesn't Modules/_randommodule.c get built? What operating system and version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 From noreply@sourceforge.net Thu May 8 20:42:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 12:42:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-734149 ] tempfile module broken in 2.3 Message-ID: Bugs item #734149, was opened at 2003-05-07 14:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 Category: Build Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile module broken in 2.3 Initial Comment: Thiserror persists since 2.3alpha >>> import tempfile Traceback (most recent call last): File "", line 1, in ? File "/roseland0/cdat/latest/lib/python2.3/tempfile.py", line 33, in ? from random import Random as _Random File "/roseland0/cdat/latest/lib/python2.3/random.py", line 61, in ? import _random ImportError: No module named _random ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-08 14:42 Message: Logged In: YES user_id=80475 Tim, do you think we should add a version number cross- check to setup.py that at least warns if the setup does not correspond the python it was designed for? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-08 14:04 Message: Logged In: YES user_id=31435 That's OK. Just don't do it again . ---------------------------------------------------------------------- Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 13:47 Message: Logged In: YES user_id=78442 Sorry, I was somewhat overwritting setup.py with one from 2.2.... My mistake ---------------------------------------------------------------------- Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 13:02 Message: Logged In: YES user_id=78442 Sorry, I forgot to specify, I'm using the "default" setup.py on Linux box, it fails on both RH8.0 and RH9.0 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-08 11:13 Message: Logged In: YES user_id=80475 Also, verify that your setup.py has a line like: exts.append( Extension("_random", ["_randommodule.c"]) ) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 20:20 Message: Logged In: YES user_id=33168 This is a build problem. Why doesn't Modules/_randommodule.c get built? What operating system and version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 From noreply@sourceforge.net Thu May 8 20:49:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 12:49:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-734149 ] tempfile module broken in 2.3 Message-ID: Bugs item #734149, was opened at 2003-05-07 15:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 Category: Build Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile module broken in 2.3 Initial Comment: Thiserror persists since 2.3alpha >>> import tempfile Traceback (most recent call last): File "", line 1, in ? File "/roseland0/cdat/latest/lib/python2.3/tempfile.py", line 33, in ? from random import Random as _Random File "/roseland0/cdat/latest/lib/python2.3/random.py", line 61, in ? import _random ImportError: No module named _random ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-08 15:49 Message: Logged In: YES user_id=31435 Dunno. Is it a common problem on systems that use setup.py (Windows doesn't, so it's a non-problem there)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-08 15:42 Message: Logged In: YES user_id=80475 Tim, do you think we should add a version number cross- check to setup.py that at least warns if the setup does not correspond the python it was designed for? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-08 15:04 Message: Logged In: YES user_id=31435 That's OK. Just don't do it again . ---------------------------------------------------------------------- Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 14:47 Message: Logged In: YES user_id=78442 Sorry, I was somewhat overwritting setup.py with one from 2.2.... My mistake ---------------------------------------------------------------------- Comment By: Charles Doutriaux (cdoutri) Date: 2003-05-08 14:02 Message: Logged In: YES user_id=78442 Sorry, I forgot to specify, I'm using the "default" setup.py on Linux box, it fails on both RH8.0 and RH9.0 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-08 12:13 Message: Logged In: YES user_id=80475 Also, verify that your setup.py has a line like: exts.append( Extension("_random", ["_randommodule.c"]) ) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-07 21:20 Message: Logged In: YES user_id=33168 This is a build problem. Why doesn't Modules/_randommodule.c get built? What operating system and version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734149&group_id=5470 From noreply@sourceforge.net Thu May 8 21:35:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 13:35:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-734844 ] pyxml setup error on Mac OS X Message-ID: Bugs item #734844, was opened at 2003-05-08 20:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734844&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gene Chow (genechow) Assigned to: Nobody/Anonymous (nobody) Summary: pyxml setup error on Mac OS X Initial Comment: Error when installing pyxml 0.8.2 on Mac OS 10.2.6 using the command: python2.1 setup.py install The following change in setup.py fixes the problem: 59c59 < distutils.sysconfig.get_config_var("LDSHARED").find("- flat_namespace") == -1: --- > get_config_vars("LDSHARED")[0].find("-flat_namespace") == -1: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734844&group_id=5470 From noreply@sourceforge.net Thu May 8 22:14:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 14:14:45 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-722647 ] lower-level API for longs Message-ID: Feature Requests item #722647, was opened at 2003-04-16 14:07 Message generated for change (Comment added) made by gregsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722647&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: lower-level API for longs Initial Comment: something to make it a little more efficient to build stuff on long integers; some simple things which are much faster to do in C than in python: e.g. n.bitwid() 1+ floor(log2(abs(n)) - # of useful bits n.bit(x) (n>>x)&1 n.bit(hi,lo) (n>>lo) & ( (1<<(hi-lo))-1) n.bitrev(m) - reverse the lower m bits of n, return that n.findup( val=1, startbit=0) "search leftwards for a bit matching 'val', starting at bit 'startbit'; -1 if none" n.finddown(val=1, startbit=n.bitwid()) " search rightwards" And some which would depend on the underlying implementation (which appears to be pretty much cast in cement, if not actual stone) : n.bitarray() returns array.array('H') containing raw bits long_fromarray(seq, neg=0) - reverse of n.bitarray If there's any interest in this, and no reason to shoot it down right away, I cld write a PEP on it. It would also be nice to have field-insertion operators, that raises the question of wether these should return a new long, or wether they should be built on a mutable 'bit-sequence' type which can act like a long. Maybe this should be an 'array-of-bit' suggestion.... ---------------------------------------------------------------------- >Comment By: Gregory Smith (gregsmith) Date: 2003-05-08 17:14 Message: Logged In: YES user_id=292741 Fair enough - it sounds like the additional methods, if any, should be kept to a minimum, and some of the other stuff that I want to do should maybe be in an add-on module rather than an addition to the core language. if/When I have some time I'll write a PEP for the methods and maybe another one for the array-of-bit support , or bitstream, or whatever it winds up being. A goal here is to be able to do variable-length coding/decoding in Python without being too slow; if I can think up a more general-purpose thing that can do that, so much the better. popcount I hadn't heard of, but Google just found it for me in a Java lib. Definitely fits into the class of things-which-go-much-faster-in-C. And yes, it makes a lot of sense to do this to ints and longs uniformly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-16 16:28 Message: Logged In: YES user_id=31435 Go for it. It has a better chance at acceptance if it sticks to inquiry methods (e.g., tie it into adding a new mutable bit array type too, and the odds plummet). Note that "bitwid" is an egregiously un-Pythonic abbreviation -- are you trying to save "th" at the end? If so, don't. Note the same methods will have to be added to ints too -- Python's trying to eradicate the user-visible differences between ints and longs, so adding methods unique to one of those types would llikely be rejected for that reason alone. Don't forget popcount (number of 1 bits set); there and elsewhere, what to do about negative inputs will be contentious. Following GMP's lead is better than making stuff up then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722647&group_id=5470 From noreply@sourceforge.net Thu May 8 22:20:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 08 May 2003 14:20:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-734869 ] Lambda functions in list comprehensions Message-ID: Bugs item #734869, was opened at 2003-05-08 21:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734869&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Finley (tomfinley) Assigned to: Nobody/Anonymous (nobody) Summary: Lambda functions in list comprehensions Initial Comment: Lambda functions that return a list built through a list comprehension used in a list comprehension cause Python to die. Example: [ (lambda a:[a**i for i in range(a+1)])(j) for j in range(5) ] You can use "map" instead of list comprehension of course (as I illustrate in my example output), so this isn't a big deal, but I think it ought to work. What follows this paragraph is an interactive session in Python, where I illustrate the workings of my lambda function to illustrate that it does work correctly in several circumstances, but not in a list comprehension. I've done this with OS X Python 2.3b1, 2.2.2, 2.2, and Solaris Python 2.2a2 with the same results. ========= Python 2.3b1 (#1, May 6 2003, 01:40:43) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> (lambda a:[a**i for i in range(a+1)])(5) [1, 5, 25, 125, 625, 3125] >>> f = lambda a:[a**i for i in range(a+1)] >>> [ f(i) for i in range(5) ] [[1], [1, 1], [1, 2, 4], [1, 3, 9, 27], [1, 4, 16, 64, 256]] >>> map(lambda a:[a**i for i in range(a+1)], range(5)) [[1], [1, 1], [1, 2, 4], [1, 3, 9, 27], [1, 4, 16, 64, 256]] >>> [ (lambda a:[a**i for i in range(a+1)])(j) for j in range(5) ] Fatal Python error: unknown scope for _[1] in (1) in symbols: {'a': 12, '_[2]': 2, 'range': 8, 'i': 10} locals: {'a': 0, '_[2]': 1, 'i': 2} globals: {'range': True} Abort ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734869&group_id=5470 From noreply@sourceforge.net Fri May 9 08:44:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 00:44:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Just van Rossum (jvr) >Assigned to: Just van Rossum (jvr) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 09:44 Message: Logged In: YES user_id=21627 The patch looks fine, and works on Linux for me. Please apply it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-06 22:51 Message: Logged In: YES user_id=92689 Here's a new attempt. Martin and I went back and forth a few times, and what I now ended up with isn't all _that_ different from the initial patch, except it no longer uses wrapped functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 23:45 Message: Logged In: YES user_id=21627 The patch is incorrect: usage of locked getaddrinfo depends on whether gethostbyname_r is supported on the platform. However, this is unrelated: A platform may have gethostbyname_r, and still not provide a thread-safe getaddrinfo, or it may not have gethostbyname_r, and yet provide a thread-safe getaddrinfo. I suggest you separate issues: 1. Should the lock variable be declared and initialized? You have two options: a) only create if needed (see below), or b) always create if Python is threaded 2. Should getaddrinfo use the lock? In general, it shouldn't, except for a few known-bad systems. 3. Should gethostbyname use the lock? Yes, unless the reentrant versions of this function are used. Notice that for Windows, gethostbyname itself is thread-safe, as it allocates a thread-local hostent. I think the lock management code is also incorrect: There is a certain moment after getaddrinfo returns where neither the GIL nor the getaddrinfo lock is held, yet Python accesses the getaddrinfo result afterwards. If getaddrinfo returns a pointer to global data, a second call could modify the result even though we have not processed it yet. I'm not sure how to solve this. It is probably safest to keep the getaddrinfo lock until freeaddrinfo has been called. Also, for systems that don't lock getaddrinfo, I would prefer if py_getaddrinfo was a define for getaddrinfo. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 20:02 Message: Logged In: YES user_id=92689 I've attached a first cut of a patch. It implements wrappers for getaddrinfo and getnameinfo, to take the burden of dealing with the lock and the GIL away from the caller. As suggested by MvL in prvt mail, I've simply reused the existing gethostbyname lock, but renamed it to netdb_lock. What needs to be reviewed carefully is when exactly USE_NETDB_LOCK (formerly known as USE_GETHOSTBYNAME_LOCK) is defined. It happens to be defined for my platform, so it "works for me". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 16:00 Message: Logged In: YES user_id=21627 Mark: the original complaint came from BSD users. So if we only release the GIL on a "good" platform, the BSD users aren't helped. Likewise, unless compiled by VC7.x, Windows users are not helped, since Python would use the getaddrinfo emulation. So if this as attempted, I think we need a best-effort solution for all systems. You could look at the Tcl lock. I recommend you look at the 2.2 sources, since the Tcl lock logic got more complicated recently (as Tcl now also has a multi-threaded mode of operation). If your platform is Mac OS X, don't trust that it is too BSDish in this respect. If both FreeBSD and NeXT had some function, Apple apparently has always chosen the NeXT version. getaddrinfo was one such case. But then, it appears that the NeXT version is even worse than the FreeBSD version. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:56 Message: Logged In: YES user_id=92689 (Never mind, I found plenty of examples in sockemodule.c itself.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:40 Message: Logged In: YES user_id=92689 Since my platform is BSD-ish, I want a lock ;-) Yes, I would like to work on a patch, except I will need some hand-holding, as I've never done anything with threads from C. Can you point me to examples of such a lock in the Python source code? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-03 14:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Fri May 9 08:45:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 00:45:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-734844 ] pyxml setup error on Mac OS X Message-ID: Bugs item #734844, was opened at 2003-05-08 22:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734844&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gene Chow (genechow) Assigned to: Nobody/Anonymous (nobody) Summary: pyxml setup error on Mac OS X Initial Comment: Error when installing pyxml 0.8.2 on Mac OS 10.2.6 using the command: python2.1 setup.py install The following change in setup.py fixes the problem: 59c59 < distutils.sysconfig.get_config_var("LDSHARED").find("- flat_namespace") == -1: --- > get_config_vars("LDSHARED")[0].find("-flat_namespace") == -1: ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 09:45 Message: Logged In: YES user_id=21627 Why do you think this is a bug in Python? The PyXML project is at sf.net/projects/pyxml. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734844&group_id=5470 From noreply@sourceforge.net Fri May 9 08:52:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 00:52:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 12:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) >Assigned to: Michael Hudson (mwh) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 09:52 Message: Logged In: YES user_id=21627 The patch is fine. If you want to look up the standardese that does or does not guarantee that these are defines, feel free to do so, but Michael doesn't need to waste its time with that. These things always have been defines on Unix, and tons of code relies on that, precisely so that you can test with an #ifdef for their presence. Some vendor may chose to break that tradition, but I would then investigate whether Python should support this vendor's systems. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 15:19 Message: Logged In: YES user_id=773482 Yep, works for me. It sure is simpler. Only thing is - do you know 100% that for every stropts.h out there, and for every one that will arise in the future, these are #defines and not actual symbols? If so, then use it (and someone should QA that on all platforms). If not - those symbols will silently vanish on some platform someday and go figure out why. Even if so, in light of PEP 11 I would at least add a comment at the appropriate point in configure.in. The comment should mention Red Hat 6.1 and glibc-2.1.2. That way, when this platform gets de-supported someday, people will be able to clean up our mess. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-08 13:38 Message: Logged In: YES user_id=6656 I think the attached patch is all that is required. Can you try it? ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 10:30 Message: Logged In: YES user_id=773482 I checked a clean copy of glib-2.1.2 from gnu.org - it indeed is missing those two symbols. Here is how to fix this bug: 1. To configure.in add the line: AC_CHECK_DECLS([I_GWROPT, I_GETCLTIME],,,[#include ]) 2. In fcntlmodule.c, surround each of the two lines that use these symbols with an #if, like so: #if defined(HAVE_DECL_I_GWROPT) && HAVE_DECL_I_GWROPT ... #endif ... #if defined(HAVE_DECL_I_GETCLTIME) && HAVE_DECL_I_GETCLTIME ... #endif ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 09:03 Message: Logged In: YES user_id=773482 I did a little historical research on this machine. It seems to have been a vanilla Red Hat 6.1 install. So I think we're going to want to support this. I worked around the problem by manually commenting out those two symbols in fcntmodule.c. I think configure needs to detect this problem and do that automatically. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 20:14 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 20:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Fri May 9 08:54:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 00:54:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-731644 ] GIL not released around getaddrinfo() Message-ID: Bugs item #731644, was opened at 2003-05-03 01:23 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Just van Rossum (jvr) Summary: GIL not released around getaddrinfo() Initial Comment: I have a situation where sock.connect() blocks in getaddrinfo(), but since the GIL isn't released around getaddrinfo() calls, other threads also block. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-09 09:54 Message: Logged In: YES user_id=92689 Thanks! Applied as socketmodule.c rev. 1.265. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 09:44 Message: Logged In: YES user_id=21627 The patch looks fine, and works on Linux for me. Please apply it. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-06 22:51 Message: Logged In: YES user_id=92689 Here's a new attempt. Martin and I went back and forth a few times, and what I now ended up with isn't all _that_ different from the initial patch, except it no longer uses wrapped functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 23:45 Message: Logged In: YES user_id=21627 The patch is incorrect: usage of locked getaddrinfo depends on whether gethostbyname_r is supported on the platform. However, this is unrelated: A platform may have gethostbyname_r, and still not provide a thread-safe getaddrinfo, or it may not have gethostbyname_r, and yet provide a thread-safe getaddrinfo. I suggest you separate issues: 1. Should the lock variable be declared and initialized? You have two options: a) only create if needed (see below), or b) always create if Python is threaded 2. Should getaddrinfo use the lock? In general, it shouldn't, except for a few known-bad systems. 3. Should gethostbyname use the lock? Yes, unless the reentrant versions of this function are used. Notice that for Windows, gethostbyname itself is thread-safe, as it allocates a thread-local hostent. I think the lock management code is also incorrect: There is a certain moment after getaddrinfo returns where neither the GIL nor the getaddrinfo lock is held, yet Python accesses the getaddrinfo result afterwards. If getaddrinfo returns a pointer to global data, a second call could modify the result even though we have not processed it yet. I'm not sure how to solve this. It is probably safest to keep the getaddrinfo lock until freeaddrinfo has been called. Also, for systems that don't lock getaddrinfo, I would prefer if py_getaddrinfo was a define for getaddrinfo. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 20:02 Message: Logged In: YES user_id=92689 I've attached a first cut of a patch. It implements wrappers for getaddrinfo and getnameinfo, to take the burden of dealing with the lock and the GIL away from the caller. As suggested by MvL in prvt mail, I've simply reused the existing gethostbyname lock, but renamed it to netdb_lock. What needs to be reviewed carefully is when exactly USE_NETDB_LOCK (formerly known as USE_GETHOSTBYNAME_LOCK) is defined. It happens to be defined for my platform, so it "works for me". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 16:00 Message: Logged In: YES user_id=21627 Mark: the original complaint came from BSD users. So if we only release the GIL on a "good" platform, the BSD users aren't helped. Likewise, unless compiled by VC7.x, Windows users are not helped, since Python would use the getaddrinfo emulation. So if this as attempted, I think we need a best-effort solution for all systems. You could look at the Tcl lock. I recommend you look at the 2.2 sources, since the Tcl lock logic got more complicated recently (as Tcl now also has a multi-threaded mode of operation). If your platform is Mac OS X, don't trust that it is too BSDish in this respect. If both FreeBSD and NeXT had some function, Apple apparently has always chosen the NeXT version. getaddrinfo was one such case. But then, it appears that the NeXT version is even worse than the FreeBSD version. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:56 Message: Logged In: YES user_id=92689 (Never mind, I found plenty of examples in sockemodule.c itself.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 15:40 Message: Logged In: YES user_id=92689 Since my platform is BSD-ish, I want a lock ;-) Yes, I would like to work on a patch, except I will need some hand-holding, as I've never done anything with threads from C. Can you point me to examples of such a lock in the Python source code? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-03 14:30 Message: Logged In: YES user_id=14198 How about simply not releasing the GIL on these platforms? Seems simpler than a new lock. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 14:18 Message: Logged In: YES user_id=21627 See python.org/sf/604210. Yes, using a separate lock would be possible. At a minimum, the BSD implementation and the getaddrinfo emulation are not thread-safe; there may be more. As I write in 604210: it would be fine if a separate lock is used only on the known-bad platforms, since the RFC states getaddrinfo is thread-safe. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-03 12:09 Message: Logged In: YES user_id=92689 Isn't that an orthogonal issue? In that we should then use a lock for getaddrinfo(), yet do release the GIL. I find it unacceptable that my GUI main thread can hang for several seconds (or more) just by doing a sock.connect() in a different thread. Short of that, can we find out on _which_ platforms getaddrinfo() isn't thread-safe and work around that? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 11:03 Message: Logged In: YES user_id=21627 This is not a bug. getaddrinfo isn't thread-safe on some systems, so we must protect it from multiple access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731644&group_id=5470 From noreply@sourceforge.net Fri May 9 08:56:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 00:56:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-733231 ] Need an easy way to check the version Message-ID: Bugs item #733231, was opened at 2003-05-06 14:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733231&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Need an easy way to check the version Initial Comment: With MacPython's Package Manager being able to install the full HTML documentation on the users' machine it would be nice if it could check the version of the documentation. Something like a version.txt (or __version__.py?) should do the trick. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 09:56 Message: Logged In: YES user_id=21627 Looking for the string Release in lib.html is not good enough? If so, I could support adding a META tag into lib.html. I'm -1 for an additional file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733231&group_id=5470 From noreply@sourceforge.net Fri May 9 09:50:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 01:50:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: Bugs item #729317, was opened at 2003-04-29 05:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a and _tkinter.TCL_VERSION is a Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 00:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 07:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Fri May 9 09:52:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 01:52:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 13:24 Message generated for change (Comment added) made by yitzg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Michael Hudson (mwh) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- Comment By: Yitz Gale (yitzg) Date: 2003-05-09 11:52 Message: Logged In: YES user_id=576391 Sounds good. Thanks much to you, Mike and Martin! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:52 Message: Logged In: YES user_id=21627 The patch is fine. If you want to look up the standardese that does or does not guarantee that these are defines, feel free to do so, but Michael doesn't need to waste its time with that. These things always have been defines on Unix, and tons of code relies on that, precisely so that you can test with an #ifdef for their presence. Some vendor may chose to break that tradition, but I would then investigate whether Python should support this vendor's systems. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 16:19 Message: Logged In: YES user_id=773482 Yep, works for me. It sure is simpler. Only thing is - do you know 100% that for every stropts.h out there, and for every one that will arise in the future, these are #defines and not actual symbols? If so, then use it (and someone should QA that on all platforms). If not - those symbols will silently vanish on some platform someday and go figure out why. Even if so, in light of PEP 11 I would at least add a comment at the appropriate point in configure.in. The comment should mention Red Hat 6.1 and glibc-2.1.2. That way, when this platform gets de-supported someday, people will be able to clean up our mess. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-08 14:38 Message: Logged In: YES user_id=6656 I think the attached patch is all that is required. Can you try it? ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 11:30 Message: Logged In: YES user_id=773482 I checked a clean copy of glib-2.1.2 from gnu.org - it indeed is missing those two symbols. Here is how to fix this bug: 1. To configure.in add the line: AC_CHECK_DECLS([I_GWROPT, I_GETCLTIME],,,[#include ]) 2. In fcntlmodule.c, surround each of the two lines that use these symbols with an #if, like so: #if defined(HAVE_DECL_I_GWROPT) && HAVE_DECL_I_GWROPT ... #endif ... #if defined(HAVE_DECL_I_GETCLTIME) && HAVE_DECL_I_GETCLTIME ... #endif ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 10:03 Message: Logged In: YES user_id=773482 I did a little historical research on this machine. It seems to have been a vanilla Red Hat 6.1 install. So I think we're going to want to support this. I worked around the problem by manually commenting out those two symbols in fcntmodule.c. I think configure needs to detect this problem and do that automatically. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:14 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 21:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Fri May 9 09:59:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 01:59:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-728277 ] Tools/msgfmt.py results in two warnings under Python 2.3b1 Message-ID: Bugs item #728277, was opened at 2003-04-27 05:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728277&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Martin v. Löwis (loewis) Summary: Tools/msgfmt.py results in two warnings under Python 2.3b1 Initial Comment: Running Tools/msgfmt.py under Python 2.3b1 (also the alphas) results in the following warnings: [sdeibel@hedgehog build-files]$ python2.3 ~/src/Python-2.3b1/Tools/i18n/msgfmt.py --help sys:1: DeprecationWarning: Non-ASCII character '\xf6' in file /home/sdeibel/src/Python-2.3b1/Tools/i18n/msgfmt.py on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details /home/sdeibel/src/Python-2.3b1/Tools/i18n/msgfmt.py:86: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up 0x950412de, # Magic Doesn't cause any problems but would be cleaner to add encoding info and the 'L' for the constant. This is on Mandrake 8.2 but I'm sure it happens everywhere. - Stephan ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:59 Message: Logged In: YES user_id=21627 Fixed in msgfmt.py 1.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728277&group_id=5470 From noreply@sourceforge.net Fri May 9 10:02:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 02:02:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-735110 ] Mach-O gcc optimisation flag can boost performance up to 10% Message-ID: Bugs item #735110, was opened at 2003-05-09 11:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735110&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: Mach-O gcc optimisation flag can boost performance up to 10% Initial Comment: This article: http://www.unsanity.org/archives/000044.php says that the -mdynamic-no-pic gcc flag can boost performance of statically linked apps around 10%. Testing this with a non-framework build of Python shows this is indeed the case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735110&group_id=5470 From noreply@sourceforge.net Fri May 9 10:06:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 02:06:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-728322 ] setup.py breaks during build of Python-2.3b1 Message-ID: Bugs item #728322, was opened at 2003-04-27 10:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728322&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Ochiltree (joch1) Assigned to: Martin v. Löwis (loewis) Summary: setup.py breaks during build of Python-2.3b1 Initial Comment: I'm having trouble building Python-2.3b1 on SuSE 8.2. The ./configure didn't seem to object to anything but running the make bombs out with: running build running build_ext Traceback (most recent call last): File "./setup.py", line 1110, in ? main() File "./setup.py", line 1105, in main scripts = ['Tools/scripts/pydoc'] File "/home/johnoch/build/Python-2.3b1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 907, in run_commands self.run_command(cmd) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/home/johnoch/build/Python-2.3b1/Lib/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/home/johnoch/build/Python-2.3b1/Lib/distutils/command/build_ext.py", line 269, in run self.build_extensions() File "./setup.py", line 99, in build_extensions self.detect_modules() File "./setup.py", line 844, in detect_modules self.detect_tkinter(inc_dirs, lib_dirs) File "./setup.py", line 941, in detect_tkinter for dir in tcl_includes + tk_includes: TypeError: unsupported operand type(s) for +: 'NoneType' and 'list' make: *** [sharedmods] Error 1 I mentioned this on comp.lang.python and received the following from Martin v Lowis: It's a typo in setup.py. Replace if (tcllib is None or tklib is None and tcl_includes is None or tk_includes is None): # Something's missing, so give up return with if (tcllib is None or tklib is None or tcl_includes is None or tk_includes is None): # Something's missing, so give up return Alternatively, install the Tcl/Tk header files if you also want to build Tkinter. Please do report bugs at sf.net/projects/python in the future; a bug report in comp.lang.python will get lost. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 11:06 Message: Logged In: YES user_id=21627 The tcllib bug was fixed in setup.py 1.162. The krb5.h bug should be fixed in setup.py 1.166. mikehsf: Please don't report new bugs in comments bugs. Instead, submit a new bug report for each new bug. ---------------------------------------------------------------------- Comment By: Mike Harrison (mikehsf) Date: 2003-05-03 07:16 Message: Logged In: YES user_id=770566 There is a similar problem on line 448 of setup.py. Instead of if krb5_h: this should read something like: if krb5_h and ssl_links is not None: Mike Harrison 5/2/2003 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728322&group_id=5470 From noreply@sourceforge.net Fri May 9 11:15:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 03:15:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-728608 ] ConfigurePython gives depreaction warning Message-ID: Bugs item #728608, was opened at 2003-04-27 23:21 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728608&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: ConfigurePython gives depreaction warning Initial Comment: ConfigurePython gives a deprecation warning for macfs, this should be suppressed. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-09 12:15 Message: Logged In: YES user_id=45365 Fixed in rev. 1.43. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728608&group_id=5470 From noreply@sourceforge.net Fri May 9 11:21:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 03:21:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-730506 ] wdg["textvariable"] and setvar/getvar not compatible Message-ID: Bugs item #730506, was opened at 2003-05-01 01:56 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: wdg["textvariable"] and setvar/getvar not compatible Initial Comment: In Python 2.2.2 and earlier, one could do: root = Tk() v = StringVar() l = Label(root, textvariable=v) l["textvariable"] and get back the name of the variable. This could then be used in l.setvar() and l.getvar() to set or get that variable. Such code is broken in Python 2.3b1 because l["textvariable"] returns a tcl object, and setvar/getvar don't recognize it. It's worth fixing because setvar and getvar seem to be the only way to deal with the thing returned by l["textvariable"]. A fix to consider is to enhance setvar and getvar so that they can deal with tcl objects (as well as with names of variables). This would still break any code that demanded a string back, but the usual reason to obtain the variable was to set or get it with setvar or getvar. So I think it would handle most problems. A less interesting fix is to have l["textvariable"] return a string. (Of course users can also disable returning objects.) A broader fix is to have l["textvariable"] return the original Tkinter Variable. That'd be truly wonderful. It would eliminate the need for setvar or getvar in all but the strangest cases (and the existing implementation would do fine in all others). It would certainly break some existing code (users would would have to disable returning objects to be fix that), but what better time to introduce it then when Tkinter is actually returning non-strings sometimes? I know I'm dreaming. I looked at Tkinter.py and it doesn't look like much fun to add (though it could be done by keeping a reference in the Tk object). -- Russell ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-09 12:21 Message: Logged In: YES user_id=45365 Closing this again: according to Martin the MacOSX Tkinter version bug is not related to the original bug of this report, and the version bug also has its own report: #729317. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-05-06 19:48 Message: Logged In: YES user_id=431773 Thank you very much for the fix! I do wish to respond to the comment "Your desired behaviour of having ["textvariable"] return a Variable object would break your own code, as setvar would again complain about a type error." str(var) returns the name of the underlying tk variable, whether var is a Tkinter Variable or a tcl object. Thus within setvar and getvar one can simply take str(arg) before using it to solve both the original bug report and also my suggested change. I plan to submit a patch to Tkinter that implements my suggested behavior and I'd hate for folks to think that it was a radical departure. In fact it is only slightly different than the current new behavior of returning a tcl object and potentially has the same solution for getvar and setvar. One gets an object back either way. The Python 2.3b1 behavior is to return an opaque tcl object; my suggestion is simply to return a non-opaque Tkinter Variable object instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-06 19:27 Message: Logged In: YES user_id=21627 This patch is likely *not* the cause of this problem. The comparison only involves a single call to getvar, and that uses a string argument. This patch didn't affect the result of getvar at all. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-06 13:23 Message: Logged In: YES user_id=45365 Tkinter now doesn't work anymore on MacOSX, at least not with Aqua Tk (the only one I tried), and I think this fix is to blame. Calling Tkinter.Tk() aborts with a RuntimeError: tcl.h version (8.4) doesn't match libtcl.a version (8.4) Inspection reveals that _tkinter.TCL_VERSION is the string "8.4", whereas self.tk.getvar('tcl_version') is the floating point number 8.4000000000000004. This specific bug can be fixed by comparing to str(tcl_version), but I'm not sure whether this is the right fix, more similar problems could be lurking out there. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-01 07:50 Message: Logged In: YES user_id=21627 This is fixed in _tkinter.c 1.156, by having getvar/setvar accept tcl objects. Your desired behaviour of having ["textvariable"] return a Variable object would break your own code, as setvar would again complain about a type error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730506&group_id=5470 From noreply@sourceforge.net Fri May 9 11:46:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 03:46:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-733781 ] fcntl fails to build on old RH Linux Message-ID: Bugs item #733781, was opened at 2003-05-07 11:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Yitzchak Gale (llxyitz) Assigned to: Michael Hudson (mwh) Summary: fcntl fails to build on old RH Linux Initial Comment: Python 2.3b1 built from source on an old RH Linux: kernel 2.2.12-20, libc 2.1.2. building 'fcntl' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I//Python-2.3b1/./Include -I/usr/local/include -I//Python-2.3b1/Include -I//Python-2.3b1 -c //Python-2.3b1/Modules/fcntlmodule.c -o build/temp.linux-i586-2.3/fcntlmodule.o //Python-2.3b1/Modules/fcntlmodule.c: In function `all_ins': //Python-2.3b1/Modules/fcntlmodule.c:555: `I_GWROPT' undeclared (first use in this function) //Python-2.3b1/Modules/fcntlmodule.c:555: (Each undeclared identifier is reported only once //Python-2.3b1/Modules/fcntlmodule.c:555: for each function it appears in.) //Python-2.3b1/Modules/fcntlmodule.c:564: `I_GETCLTIME' undeclared (first use in this function) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-05-09 11:46 Message: Logged In: YES user_id=6656 Done: Modules/fcntlmodule.c revision 2.40 ---------------------------------------------------------------------- Comment By: Yitz Gale (yitzg) Date: 2003-05-09 09:52 Message: Logged In: YES user_id=576391 Sounds good. Thanks much to you, Mike and Martin! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 08:52 Message: Logged In: YES user_id=21627 The patch is fine. If you want to look up the standardese that does or does not guarantee that these are defines, feel free to do so, but Michael doesn't need to waste its time with that. These things always have been defines on Unix, and tons of code relies on that, precisely so that you can test with an #ifdef for their presence. Some vendor may chose to break that tradition, but I would then investigate whether Python should support this vendor's systems. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 14:19 Message: Logged In: YES user_id=773482 Yep, works for me. It sure is simpler. Only thing is - do you know 100% that for every stropts.h out there, and for every one that will arise in the future, these are #defines and not actual symbols? If so, then use it (and someone should QA that on all platforms). If not - those symbols will silently vanish on some platform someday and go figure out why. Even if so, in light of PEP 11 I would at least add a comment at the appropriate point in configure.in. The comment should mention Red Hat 6.1 and glibc-2.1.2. That way, when this platform gets de-supported someday, people will be able to clean up our mess. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-08 12:38 Message: Logged In: YES user_id=6656 I think the attached patch is all that is required. Can you try it? ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 09:30 Message: Logged In: YES user_id=773482 I checked a clean copy of glib-2.1.2 from gnu.org - it indeed is missing those two symbols. Here is how to fix this bug: 1. To configure.in add the line: AC_CHECK_DECLS([I_GWROPT, I_GETCLTIME],,,[#include ]) 2. In fcntlmodule.c, surround each of the two lines that use these symbols with an #if, like so: #if defined(HAVE_DECL_I_GWROPT) && HAVE_DECL_I_GWROPT ... #endif ... #if defined(HAVE_DECL_I_GETCLTIME) && HAVE_DECL_I_GETCLTIME ... #endif ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-08 08:03 Message: Logged In: YES user_id=773482 I did a little historical research on this machine. It seems to have been a vanilla Red Hat 6.1 install. So I think we're going to want to support this. I worked around the problem by manually commenting out those two symbols in fcntmodule.c. I think configure needs to detect this problem and do that automatically. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 19:14 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- Comment By: Yitzchak Gale (llxyitz) Date: 2003-05-07 19:07 Message: Logged In: YES user_id=773482 fcntlmodule.c states: /* Unix 98 guarantees that these are in stropts.h. */ Those two symbols are missing in mine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733781&group_id=5470 From noreply@sourceforge.net Fri May 9 12:19:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 04:19:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-734869 ] Lambda functions in list comprehensions Message-ID: Bugs item #734869, was opened at 2003-05-08 22:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734869&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Finley (tomfinley) >Assigned to: Jeremy Hylton (jhylton) Summary: Lambda functions in list comprehensions Initial Comment: Lambda functions that return a list built through a list comprehension used in a list comprehension cause Python to die. Example: [ (lambda a:[a**i for i in range(a+1)])(j) for j in range(5) ] You can use "map" instead of list comprehension of course (as I illustrate in my example output), so this isn't a big deal, but I think it ought to work. What follows this paragraph is an interactive session in Python, where I illustrate the workings of my lambda function to illustrate that it does work correctly in several circumstances, but not in a list comprehension. I've done this with OS X Python 2.3b1, 2.2.2, 2.2, and Solaris Python 2.2a2 with the same results. ========= Python 2.3b1 (#1, May 6 2003, 01:40:43) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> (lambda a:[a**i for i in range(a+1)])(5) [1, 5, 25, 125, 625, 3125] >>> f = lambda a:[a**i for i in range(a+1)] >>> [ f(i) for i in range(5) ] [[1], [1, 1], [1, 2, 4], [1, 3, 9, 27], [1, 4, 16, 64, 256]] >>> map(lambda a:[a**i for i in range(a+1)], range(5)) [[1], [1, 1], [1, 2, 4], [1, 3, 9, 27], [1, 4, 16, 64, 256]] >>> [ (lambda a:[a**i for i in range(a+1)])(j) for j in range(5) ] Fatal Python error: unknown scope for _[1] in (1) in symbols: {'a': 12, '_[2]': 2, 'range': 8, 'i': 10} locals: {'a': 0, '_[2]': 1, 'i': 2} globals: {'range': True} Abort ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-05-09 12:19 Message: Logged In: YES user_id=6656 Argh. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734869&group_id=5470 From noreply@sourceforge.net Fri May 9 13:46:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 05:46:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-09 13:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 15:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 21:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 01:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 18:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 09:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 16:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 16:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 21:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 21:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 21:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 20:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Fri May 9 15:00:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 07:00:57 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-734115 ] Packaging without disturbing an existing installation Message-ID: Feature Requests item #734115, was opened at 2003-05-07 20:42 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=734115&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Mansfield (stmansfield) Assigned to: Nobody/Anonymous (nobody) Summary: Packaging without disturbing an existing installation Initial Comment: As a developer/maintainer of a custom embedded GNU/Linux distribution, I need to be able to build and package various components that make up this operating system in as convenient, painless manner possible. One thing that is missing from the Python build process is the ability to specify an alternate destination directory for packaging concerns. To that end, at the request of one of the 'python-help' volunteers (thanks Matt!) I am submitting this feature request and patch. This patch will modify the 'Makefile.pre.in' file, prepending a DESTDIR in front installation target directories. Note that this is pretty much de-facto standard behavior for most autoconf- automake- type builds. This will not alter the 'prefix', 'execprefix' or other directories that hinge on same. Once this patch is applied and the sources are successfully built, one could do a "make DESTDIR='/opt/pkg' install" and have the installtion faithfully reproduced under '/opt/pkg' (example directory only), and create a finished, deployable package; saving one from having to suffer the pain of having to pick through /usr, and also saving the pain of potentially over-writing whatever existing installation might exist on the build machine. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-09 16:00 Message: Logged In: YES user_id=45365 I would be interested in this as well, as it would simplify MacOSX binary installer building too. For a quick inspection I also think that the patch isn't complete for MacOSX framework builds (where part of the installation is done in Mac/OSX/ Makefile), I will try to find time to test the patch but it could be another 2 weeks before I get around to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=734115&group_id=5470 From noreply@sourceforge.net Fri May 9 15:06:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 07:06:24 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-223599 ] Need user-centered info for Windows users. Message-ID: Feature Requests item #223599, was opened at 2000-11-27 17:31 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=223599&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Need user-centered info for Windows users. Initial Comment: Users ask questions like "How do I write batch files using Python?"; there should be a document that acts as a user's guide specifically for Windows users. This could be similar to what the Macintosh Modules Reference is becoming. This should be part of the standard documentation and could acquire the Windows module documentation. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-09 16:06 Message: Logged In: YES user_id=45365 Slightly off on a tangent, but may be worthwhile anyway: MacPython now has an Apple Help Book (html files with some sugar coating) that is meant as the very first thing to get people started. This might be a starting point for a similar help document for Windows. The sources are in Mac/OSXResources/app/Resources/English.lproj/ Documentation. ---------------------------------------------------------------------- Comment By: Kevin Cathcart (dev314159) Date: 2002-08-05 18:35 Message: Logged In: YES user_id=589477 > This one comes up most with first time programmers and >users from environments that don't expose source code as >editable text files (VB?). actually VB can make most files into editable source files. (this option is found in the save dailog in most versions) but that is besides the point) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 11:48 Message: Logged In: YES user_id=21627 Moved into feature requests tracker. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-18 05:28 Message: Logged In: NO is it a really bad effect after i batch the file ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-07 17:46 Message: Logged In: NO hello! i am wantin! plz ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 23:37 Message: Logged In: YES user_id=31392 Can we move this out of bugs and into feature requests? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-01-22 17:04 Message: Another question that should be answered in this document: "How do I create/recall modules?" This one comes up most with first time programmers and users from environments that don't expose source code as editable text files (VB?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=223599&group_id=5470 From noreply@sourceforge.net Fri May 9 15:08:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 07:08:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-735247 ] Memory leak concerning super and staticmethod Message-ID: Bugs item #735247, was opened at 2003-05-09 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=735247&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak concerning super and staticmethod Initial Comment: def test_leak(self): # XXX Leaky. This is the same leak as in test_subclass_constructor, # but isolated to depend only on code in Python 2.2.2. # It still leaks on the release22-maint branch, but not with # Python 2.3 from CVS HEAD. class SomeClass(object): def somemethod(): # XXX The next line produces the following leak: # # totalrefcount=233207 change=32 # 3 12 # 1 7 # 1 5 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 0 10 # 0 1 # 0 1 super(SomeClass, None) somemethod = staticmethod(somemethod) SomeClass.somemethod() The above was taken from Zope 3 CVS. http://cvs.zope.org/Zope3/src/zope/proxy/tests/test_proxy.py.diff?r1=1.6&r2=1.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 From noreply@sourceforge.net Fri May 9 15:09:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 07:09:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-735248 ] urllib2 parse_http_list wrong return Message-ID: Bugs item #735248, was opened at 2003-05-09 10: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=735248&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 parse_http_list wrong return Initial Comment: parse_http_list should split a string on commas, unless the commas are within a quoted-string. (It allows only the "" quote, and not the single-quote, but this seems to follow the RFC.) If there are not quoted-strings, it repeats the first tokens as part of subsequent tokens. parse_http_list ('a,b') => ['a','a,b'] It should return ['a','b'] parse_http_list ('a,b,c') => ['a','a,b','a,b,c'] It should return ['a','b','c'] Patch: On (cvs version) line 882, when no quote is found and inquote is false, reset the start position to after the comma. if q == -1: if inquote: raise ValueError, "unbalanced quotes" else: list.append(s[start:i+c]) i = i + c + 1 start = i #New line continue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735248&group_id=5470 From noreply@sourceforge.net Fri May 9 15:10:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 07:10:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-735247 ] Memory leak concerning super and staticmethod Message-ID: Bugs item #735247, was opened at 2003-05-09 14:08 Message generated for change (Comment added) made by stevea_zope You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak concerning super and staticmethod Initial Comment: def test_leak(self): # XXX Leaky. This is the same leak as in test_subclass_constructor, # but isolated to depend only on code in Python 2.2.2. # It still leaks on the release22-maint branch, but not with # Python 2.3 from CVS HEAD. class SomeClass(object): def somemethod(): # XXX The next line produces the following leak: # # totalrefcount=233207 change=32 # 3 12 # 1 7 # 1 5 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 0 10 # 0 1 # 0 1 super(SomeClass, None) somemethod = staticmethod(somemethod) SomeClass.somemethod() The above was taken from Zope 3 CVS. http://cvs.zope.org/Zope3/src/zope/proxy/tests/test_proxy.py.diff?r1=1.6&r2=1.7 ---------------------------------------------------------------------- >Comment By: Steve Alexander (stevea_zope) Date: 2003-05-09 14:10 Message: Logged In: YES user_id=492001 Darn, the formatting isn't preserved. Look at the HTTP link at the bottom. The method in question is all that changed in the diff highlighted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 From noreply@sourceforge.net Fri May 9 15:54:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 07:54:18 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-734115 ] Packaging without disturbing an existing installation Message-ID: Feature Requests item #734115, was opened at 2003-05-07 11:42 Message generated for change (Comment added) made by stmansfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=734115&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Mansfield (stmansfield) Assigned to: Nobody/Anonymous (nobody) Summary: Packaging without disturbing an existing installation Initial Comment: As a developer/maintainer of a custom embedded GNU/Linux distribution, I need to be able to build and package various components that make up this operating system in as convenient, painless manner possible. One thing that is missing from the Python build process is the ability to specify an alternate destination directory for packaging concerns. To that end, at the request of one of the 'python-help' volunteers (thanks Matt!) I am submitting this feature request and patch. This patch will modify the 'Makefile.pre.in' file, prepending a DESTDIR in front installation target directories. Note that this is pretty much de-facto standard behavior for most autoconf- automake- type builds. This will not alter the 'prefix', 'execprefix' or other directories that hinge on same. Once this patch is applied and the sources are successfully built, one could do a "make DESTDIR='/opt/pkg' install" and have the installtion faithfully reproduced under '/opt/pkg' (example directory only), and create a finished, deployable package; saving one from having to suffer the pain of having to pick through /usr, and also saving the pain of potentially over-writing whatever existing installation might exist on the build machine. ---------------------------------------------------------------------- >Comment By: Scott Mansfield (stmansfield) Date: 2003-05-09 07:54 Message: Logged In: YES user_id=566409 I just had another look at the changes I made to the Makefile.pre.in, it will /not/ work for Mac OS X at this time. I do my development at work on an x86 host, but have Mac OS X at home. I'll try to update the patch file this weekend (5/10/2003) so the 'Framework' makefile target is properly handled. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-09 07:00 Message: Logged In: YES user_id=45365 I would be interested in this as well, as it would simplify MacOSX binary installer building too. For a quick inspection I also think that the patch isn't complete for MacOSX framework builds (where part of the installation is done in Mac/OSX/ Makefile), I will try to find time to test the patch but it could be another 2 weeks before I get around to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=734115&group_id=5470 From noreply@sourceforge.net Fri May 9 16:07:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 08:07:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-735274 ] FILEMODE not honoured Message-ID: Bugs item #735274, was opened at 2003-05-09 17: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=735274&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: FILEMODE not honoured Initial Comment: The Python build process doesn't honour the FILEMODE setting in Makefile.pre.in (or passed in at install time with "make FILEMODE=664 install") because configure sets the install command to an explicit "${INSTALL} -m 644" in stead of to "${INSTALL} -m ${FILEMODE}". DIRMODE and EXEMODE are handled correctly. Please let me know whether you agree and assign back to me, if you agree I'll put the changes in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735274&group_id=5470 From noreply@sourceforge.net Fri May 9 16:09:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 08:09:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-735276 ] tuple.__mul__ won't work with string format Message-ID: Bugs item #735276, was opened at 2003-05-09 11:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735276&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Clark Updike (cupdike) Assigned to: Nobody/Anonymous (nobody) Summary: tuple.__mul__ won't work with string format Initial Comment: Tuple multiplication doesn't feed string format properly. Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> '%s%s' % ('x','x') 'xx' >>> ('x',)*2 == ('x','x') 1 >>> '%s%s' % ('x',)*2 Traceback (most recent call last): File "", line 1, in ? TypeError: not enough arguments for format string >>> '%s%s' % tuple(('x',)*2) 'xx' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735276&group_id=5470 From noreply@sourceforge.net Fri May 9 16:10:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 08:10:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-733199 ] OSX installer problem with pydoc Message-ID: Bugs item #733199, was opened at 2003-05-06 12:52 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733199&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: OSX installer problem with pydoc Initial Comment: >From Bob Talbert: Just a quick note that the pydoc that gets installed as part of 2.3b1 has a typo in the #! line. Can't quite see why it is hardcoded this way, but the line reads: #!/tmp/_py/install/Library/Frameworks/Python.framework/Versions/ 2.3/bin/python when it should be: #!/Library/Frameworks/Python.framework/Versions/2.3/bin/python ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-09 17:10 Message: Logged In: YES user_id=45365 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733199&group_id=5470 From noreply@sourceforge.net Fri May 9 16:20:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 08:20:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-735276 ] tuple.__mul__ won't work with string format Message-ID: Bugs item #735276, was opened at 2003-05-09 16:09 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735276&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Clark Updike (cupdike) >Assigned to: Michael Hudson (mwh) Summary: tuple.__mul__ won't work with string format Initial Comment: Tuple multiplication doesn't feed string format properly. Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> '%s%s' % ('x','x') 'xx' >>> ('x',)*2 == ('x','x') 1 >>> '%s%s' % ('x',)*2 Traceback (most recent call last): File "", line 1, in ? TypeError: not enough arguments for format string >>> '%s%s' % tuple(('x',)*2) 'xx' >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-05-09 16:20 Message: Logged In: YES user_id=6656 * and % have the same precedence and associate to the left: >>> '%s%s' % (('x',)*2 ) 'xx' (there's a rant in here about overloading operators, but I'll save that for another time...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735276&group_id=5470 From noreply@sourceforge.net Fri May 9 16:36:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 08:36:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-735293 ] Command line timeit.py sets sys.path badly Message-ID: Bugs item #735293, was opened at 2003-05-09 16: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=735293&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Command line timeit.py sets sys.path badly Initial Comment: Running timeit.py from the command line results in the directory containing timeit.py (ie, the standard Python library) being added to sys.path, and the current directory *not* being. To test, create a file mymod.py in the current directory, containing def test(): "Stupid test function" L = [] for i in range(100): L.append(i) Now, execute \Apps\Python\Lib\timeit.py -s "import mymod" "mymod.test()" Result is Traceback (most recent call last): File "\Apps\Python\Lib\timeit.py", line 245, in main x = t.timeit(number) File "\Apps\Python\Lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "", line 3, in inner import mymod ImportError: No module named mymod It's possible to work around this, either by setting PYTHONPATH in the environment to ".", or by adding "import sys; sys.path.insert(0, '.')" to the code in the -s option. But neither is a particularly attractive solution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 From noreply@sourceforge.net Fri May 9 16:47:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 08:47:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-735301 ] timeit.py doesn't see module globals Message-ID: Bugs item #735301, was opened at 2003-05-09 16:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: timeit.py doesn't see module globals Initial Comment: Simple test file (save as test.py) def test(): "Stupid test function" L = [] for i in range(100): L.append(i) if __name__=='__main__': from timeit import Timer t = Timer("test()") print t.timeit() Try to run this, and the following traceback occurs: >test.py Traceback (most recent call last): File "C:\Data\graph\test.py", line 10, in ? print t.timeit() File "C:\Apps\Python\lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "", line 6, in inner NameError: global name 'test' is not defined ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 From noreply@sourceforge.net Fri May 9 17:40:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 09:40:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-735247 ] Memory leak concerning super and staticmethod Message-ID: Bugs item #735247, was opened at 2003-05-09 14:08 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) >Assigned to: Jeremy Hylton (jhylton) Summary: Memory leak concerning super and staticmethod Initial Comment: def test_leak(self): # XXX Leaky. This is the same leak as in test_subclass_constructor, # but isolated to depend only on code in Python 2.2.2. # It still leaks on the release22-maint branch, but not with # Python 2.3 from CVS HEAD. class SomeClass(object): def somemethod(): # XXX The next line produces the following leak: # # totalrefcount=233207 change=32 # 3 12 # 1 7 # 1 5 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 0 10 # 0 1 # 0 1 super(SomeClass, None) somemethod = staticmethod(somemethod) SomeClass.somemethod() The above was taken from Zope 3 CVS. http://cvs.zope.org/Zope3/src/zope/proxy/tests/test_proxy.py.diff?r1=1.6&r2=1.7 ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 16:40 Message: Logged In: YES user_id=31392 steve: is this bug report just a reminder to backport this fixes from 2.3? ---------------------------------------------------------------------- Comment By: Steve Alexander (stevea_zope) Date: 2003-05-09 14:10 Message: Logged In: YES user_id=492001 Darn, the formatting isn't preserved. Look at the HTTP link at the bottom. The method in question is all that changed in the diff highlighted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 From noreply@sourceforge.net Fri May 9 17:47:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 09:47:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-735248 ] urllib2 parse_http_list wrong return Message-ID: Bugs item #735248, was opened at 2003-05-09 14:09 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735248&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 parse_http_list wrong return Initial Comment: parse_http_list should split a string on commas, unless the commas are within a quoted-string. (It allows only the "" quote, and not the single-quote, but this seems to follow the RFC.) If there are not quoted-strings, it repeats the first tokens as part of subsequent tokens. parse_http_list ('a,b') => ['a','a,b'] It should return ['a','b'] parse_http_list ('a,b,c') => ['a','a,b','a,b,c'] It should return ['a','b','c'] Patch: On (cvs version) line 882, when no quote is found and inquote is false, reset the start position to after the comma. if q == -1: if inquote: raise ValueError, "unbalanced quotes" else: list.append(s[start:i+c]) i = i + c + 1 start = i #New line continue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735248&group_id=5470 From noreply@sourceforge.net Fri May 9 18:03:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 10:03:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-735247 ] Memory leak concerning super and staticmethod Message-ID: Bugs item #735247, was opened at 2003-05-09 14:08 Message generated for change (Comment added) made by stevea_zope You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Jeremy Hylton (jhylton) Summary: Memory leak concerning super and staticmethod Initial Comment: def test_leak(self): # XXX Leaky. This is the same leak as in test_subclass_constructor, # but isolated to depend only on code in Python 2.2.2. # It still leaks on the release22-maint branch, but not with # Python 2.3 from CVS HEAD. class SomeClass(object): def somemethod(): # XXX The next line produces the following leak: # # totalrefcount=233207 change=32 # 3 12 # 1 7 # 1 5 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 0 10 # 0 1 # 0 1 super(SomeClass, None) somemethod = staticmethod(somemethod) SomeClass.somemethod() The above was taken from Zope 3 CVS. http://cvs.zope.org/Zope3/src/zope/proxy/tests/test_proxy.py.diff?r1=1.6&r2=1.7 ---------------------------------------------------------------------- >Comment By: Steve Alexander (stevea_zope) Date: 2003-05-09 17:03 Message: Logged In: YES user_id=492001 This is a bug report against Python 2.2.2, and the Python 2.2 maintenance branch in CVS. I'd like to see this fixed for Python 2.2.3, as it will stop a Zope 3 test from leaking. The obvious way to fix it is to backport stuff from Python 2.3. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 16:40 Message: Logged In: YES user_id=31392 steve: is this bug report just a reminder to backport this fixes from 2.3? ---------------------------------------------------------------------- Comment By: Steve Alexander (stevea_zope) Date: 2003-05-09 14:10 Message: Logged In: YES user_id=492001 Darn, the formatting isn't preserved. Look at the HTTP link at the bottom. The method in question is all that changed in the diff highlighted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 From noreply@sourceforge.net Fri May 9 18:32:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 10:32:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 18:39 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 17:32 Message: Logged In: YES user_id=31392 Currently, a new-style class that defines __cmp__ but not __hash__ is usable as a dictionary key. That seems related to this bug. Should I paste the example here and bump the priority? Or should I open a separate bug report? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 23:01 Message: Logged In: YES user_id=6380 I spent an afternoon looking into this, and I can't see an easy solution. The idea of only inheriting __hash__ together with certain other slots is really flawed; it may be better if object DIDN'T define a default implementation for __hash__, comparisons (both flavors), and other things, or maybe the default __hash__ should raise an exception when the comparisons are not those inherited from object, or maybe PyType_Ready should insert a dummy __hash__ when it sees that you redefine __eq__, or... I really don't know. I'm going to sleep on this some more, and lower the priority. You can always get the right behavior by explicitly defining __hash__. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 18:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 18:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Fri May 9 18:44:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 10:44:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 13:44 Message: Logged In: YES user_id=6380 Yes, please paste an example here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 13:32 Message: Logged In: YES user_id=31392 Currently, a new-style class that defines __cmp__ but not __hash__ is usable as a dictionary key. That seems related to this bug. Should I paste the example here and bump the priority? Or should I open a separate bug report? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I spent an afternoon looking into this, and I can't see an easy solution. The idea of only inheriting __hash__ together with certain other slots is really flawed; it may be better if object DIDN'T define a default implementation for __hash__, comparisons (both flavors), and other things, or maybe the default __hash__ should raise an exception when the comparisons are not those inherited from object, or maybe PyType_Ready should insert a dummy __hash__ when it sees that you redefine __eq__, or... I really don't know. I'm going to sleep on this some more, and lower the priority. You can always get the right behavior by explicitly defining __hash__. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 13:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Fri May 9 18:54:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 10:54:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-09 13:54 Message: Logged In: YES user_id=31435 >>> class C: # classic class complains ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} Traceback (most recent call last): File "", line 1, in ? TypeError: unhashable instance >>> class C(object): # new-style class does not complain ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} {<__main__.C object at 0x007F6970>: 1} >>> That was under current CVS. I see the same behavior in 2.2.3, so this isn't new. About Thomas's original report, I don't agree -- the default behavior is very useful. The rule I've always lived by is that, to be usable as a dict key, an instance's class must either: 1. Implement none of {__cmp__, __eq__, __hash__}. or 2. Implement __hash__ and (at least) one of {__cmp, __eq__}. Classic classes still work this way. New-style classes don't appear to outlaw any combination here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 13:44 Message: Logged In: YES user_id=6380 Yes, please paste an example here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 13:32 Message: Logged In: YES user_id=31392 Currently, a new-style class that defines __cmp__ but not __hash__ is usable as a dictionary key. That seems related to this bug. Should I paste the example here and bump the priority? Or should I open a separate bug report? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I spent an afternoon looking into this, and I can't see an easy solution. The idea of only inheriting __hash__ together with certain other slots is really flawed; it may be better if object DIDN'T define a default implementation for __hash__, comparisons (both flavors), and other things, or maybe the default __hash__ should raise an exception when the comparisons are not those inherited from object, or maybe PyType_Ready should insert a dummy __hash__ when it sees that you redefine __eq__, or... I really don't know. I'm going to sleep on this some more, and lower the priority. You can always get the right behavior by explicitly defining __hash__. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 13:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Fri May 9 19:04:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 11:04:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 14:04 Message: Logged In: YES user_id=6380 A trick similar to what we do in object_new might work. There, we raise an error if the tp_init slot is the default function (object_init) and any arguments are passed. I propose that object_hash checks that tp_compare and tp_richcompare are both NULL. I'm attaching a patch -- let me know if that works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-09 13:54 Message: Logged In: YES user_id=31435 >>> class C: # classic class complains ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} Traceback (most recent call last): File "", line 1, in ? TypeError: unhashable instance >>> class C(object): # new-style class does not complain ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} {<__main__.C object at 0x007F6970>: 1} >>> That was under current CVS. I see the same behavior in 2.2.3, so this isn't new. About Thomas's original report, I don't agree -- the default behavior is very useful. The rule I've always lived by is that, to be usable as a dict key, an instance's class must either: 1. Implement none of {__cmp__, __eq__, __hash__}. or 2. Implement __hash__ and (at least) one of {__cmp, __eq__}. Classic classes still work this way. New-style classes don't appear to outlaw any combination here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 13:44 Message: Logged In: YES user_id=6380 Yes, please paste an example here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 13:32 Message: Logged In: YES user_id=31392 Currently, a new-style class that defines __cmp__ but not __hash__ is usable as a dictionary key. That seems related to this bug. Should I paste the example here and bump the priority? Or should I open a separate bug report? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I spent an afternoon looking into this, and I can't see an easy solution. The idea of only inheriting __hash__ together with certain other slots is really flawed; it may be better if object DIDN'T define a default implementation for __hash__, comparisons (both flavors), and other things, or maybe the default __hash__ should raise an exception when the comparisons are not those inherited from object, or maybe PyType_Ready should insert a dummy __hash__ when it sees that you redefine __eq__, or... I really don't know. I'm going to sleep on this some more, and lower the priority. You can always get the right behavior by explicitly defining __hash__. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 13:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Fri May 9 19:06:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 11:06:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-735301 ] timeit.py doesn't see module globals Message-ID: Bugs item #735301, was opened at 2003-05-09 11:47 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: timeit.py doesn't see module globals Initial Comment: Simple test file (save as test.py) def test(): "Stupid test function" L = [] for i in range(100): L.append(i) if __name__=='__main__': from timeit import Timer t = Timer("test()") print t.timeit() Try to run this, and the following traceback occurs: >test.py Traceback (most recent call last): File "C:\Data\graph\test.py", line 10, in ? print t.timeit() File "C:\Apps\Python\lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "", line 6, in inner NameError: global name 'test' is not defined ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 14:06 Message: Logged In: YES user_id=6380 You must import the test function from __main__ in the setup code fragment, e.g. t = Timer("test()", "from __main__ import test") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 From noreply@sourceforge.net Fri May 9 19:22:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 11:22:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-735301 ] timeit.py doesn't see module globals Message-ID: Bugs item #735301, was opened at 2003-05-09 10:47 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: timeit.py doesn't see module globals Initial Comment: Simple test file (save as test.py) def test(): "Stupid test function" L = [] for i in range(100): L.append(i) if __name__=='__main__': from timeit import Timer t = Timer("test()") print t.timeit() Try to run this, and the following traceback occurs: >test.py Traceback (most recent call last): File "C:\Data\graph\test.py", line 10, in ? print t.timeit() File "C:\Apps\Python\lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "", line 6, in inner NameError: global name 'test' is not defined ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-09 13:22 Message: Logged In: YES user_id=44345 I added an example of this to the module documentation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 13:06 Message: Logged In: YES user_id=6380 You must import the test function from __main__ in the setup code fragment, e.g. t = Timer("test()", "from __main__ import test") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 From noreply@sourceforge.net Fri May 9 19:30:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 11:30:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-735247 ] Memory leak concerning super and staticmethod Message-ID: Bugs item #735247, was opened at 2003-05-09 14:08 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Jeremy Hylton (jhylton) Summary: Memory leak concerning super and staticmethod Initial Comment: def test_leak(self): # XXX Leaky. This is the same leak as in test_subclass_constructor, # but isolated to depend only on code in Python 2.2.2. # It still leaks on the release22-maint branch, but not with # Python 2.3 from CVS HEAD. class SomeClass(object): def somemethod(): # XXX The next line produces the following leak: # # totalrefcount=233207 change=32 # 3 12 # 1 7 # 1 5 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 1 4 # 0 10 # 0 1 # 0 1 super(SomeClass, None) somemethod = staticmethod(somemethod) SomeClass.somemethod() The above was taken from Zope 3 CVS. http://cvs.zope.org/Zope3/src/zope/proxy/tests/test_proxy.py.diff?r1=1.6&r2=1.7 ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 18:30 Message: Logged In: YES user_id=31392 Fixed in rev 2.73.2.1.2.5 of Modules/cPickle.c rev 2.50.4.2 of Objects/funcobject.c ---------------------------------------------------------------------- Comment By: Steve Alexander (stevea_zope) Date: 2003-05-09 17:03 Message: Logged In: YES user_id=492001 This is a bug report against Python 2.2.2, and the Python 2.2 maintenance branch in CVS. I'd like to see this fixed for Python 2.2.3, as it will stop a Zope 3 test from leaking. The obvious way to fix it is to backport stuff from Python 2.3. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 16:40 Message: Logged In: YES user_id=31392 steve: is this bug report just a reminder to backport this fixes from 2.3? ---------------------------------------------------------------------- Comment By: Steve Alexander (stevea_zope) Date: 2003-05-09 14:10 Message: Logged In: YES user_id=492001 Darn, the formatting isn't preserved. Look at the HTTP link at the bottom. The method in question is all that changed in the diff highlighted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735247&group_id=5470 From noreply@sourceforge.net Sat May 10 01:14:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 17:14:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-10 01:14 Message: Logged In: YES user_id=261020 OK, I can't test IE, because Windows doesn't have a proper loopback adapter, and my Windows machine is disconnected. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 15:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 21:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 01:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 18:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 09:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 16:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 16:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 21:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 21:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 21:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 20:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Sat May 10 01:21:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 17:21:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-735515 ] urllib / urllib2 should cache 301 redirections Message-ID: Bugs item #735515, was opened at 2003-05-10 01:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735515&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib / urllib2 should cache 301 redirections Initial Comment: urllib / urllib2 should cache the results of 301 (permanent) redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC (2616, section 10.3.2, first para) says SHOULD happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735515&group_id=5470 From noreply@sourceforge.net Sat May 10 02:49:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 18:49:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-735535 ] cStringIO.StringIO Message-ID: Bugs item #735535, was opened at 2003-05-09 21:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735535&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO.StringIO Initial Comment: Instance of cStringIO.StringIO have no __class__ attribute. Other built-in types, such as cPickle.Pickler, do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735535&group_id=5470 From noreply@sourceforge.net Sat May 10 03:44:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 19:44:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: Bugs item #729317, was opened at 2003-04-29 03:41 Message generated for change (Comment added) made by thunderbug You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a and _tkinter.TCL_VERSION is a Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Larry Bugbee (thunderbug) Date: 2003-05-10 02:44 Message: Logged In: YES user_id=10953 Several of us have encountered this. Personally, I have seen this with Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2. ...and with Tcl/Tk 8.4.2. ...and under 10.2.5 and 2.3b1. I've tried several combinations. My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/ python/mac/ . I hope this helps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 08:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 22:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 05:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Sat May 10 04:59:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 20:59:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-735535 ] cStringIO.StringIO Message-ID: Bugs item #735535, was opened at 2003-05-09 20:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735535&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO.StringIO Initial Comment: Instance of cStringIO.StringIO have no __class__ attribute. Other built-in types, such as cPickle.Pickler, do. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-09 22:59 Message: Logged In: YES user_id=80475 Which version are you using? I don't see the same thing: >>> a = cStringIO.StringIO('the quick') >>> type(a) >>> a.__class__ >>> b = cStringIO.StringIO() >>> type(b) >>> b.__class__ >>> dir(a) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__h ash__', '__init__', '__iter__', '__new__', '__reduce__', '__redu ce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'flush', 'g etvalue', 'isatty', 'next', 'read', 'readline', 'readlines', 'reset', ' seek', 'tell', 'truncate'] >>> dir(b) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__h ash__', '__init__', '__iter__', '__new__', '__reduce__', '__redu ce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'flush', 'g etvalue', 'isatty', 'next', 'read', 'readline', 'readlines', 'reset', ' seek', 'softspace', 'tell', 'truncate', 'write', 'writelines'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735535&group_id=5470 From noreply@sourceforge.net Sat May 10 08:29:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 00:29:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: Bugs item #729317, was opened at 2003-04-29 05:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) >Assigned to: Jack Jansen (jackjansen) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a and _tkinter.TCL_VERSION is a Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:29 Message: Logged In: YES user_id=21627 This seems to happen only in the Mac version of Tcl. I can't reproduce it on Linux or Windows, and I can't see anything in the Tcl sources that may causing it. tcl_version is set in generic/tclBasic.c using Tcl_SetVar, i.e. as a string. It is never referred-to in the Tcl sources, except for being returned from 'info tclversion'. So I can't see why it would ever be changed to a floating point object. Perhaps the Mac is not using the original Tcl source code? Assigning to Jack for further investigation. ---------------------------------------------------------------------- Comment By: Larry Bugbee (thunderbug) Date: 2003-05-10 04:44 Message: Logged In: YES user_id=10953 Several of us have encountered this. Personally, I have seen this with Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2. ...and with Tcl/Tk 8.4.2. ...and under 10.2.5 and 2.3b1. I've tried several combinations. My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/ python/mac/ . I hope this helps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 00:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 07:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Sat May 10 12:44:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 04:44:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-735674 ] libwinsound.tex is missing MessageBeep() description Message-ID: Bugs item #735674, was opened at 2003-05-10 13: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=735674&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: libwinsound.tex is missing MessageBeep() description Initial Comment: libwinsound.tex is missing a description of the MessageBeep() function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 From noreply@sourceforge.net Sat May 10 13:45:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 05:45:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-10 13:45 Message: Logged In: YES user_id=261020 Sorry for all these tiny updates. Summary of what remains to be done: 1. Apply Guido's patch for urllib.py: guido.txt. The docs are already correct. 2. 301 in response to POST is still not redirected in urllib2. urllib2.py.patch3 fixes that (note patch3, not patch2). It also removes my Request.get_method method (which now seems like overkill, as well as breaking the URL scheme-independence of Request). Also fixes an exception message. 3. liburllib2.tex.patch2 updates the docs to reflect the changes in urllib2.py.patch3, rephrases a note and adds a missing method description. 4. liburllib.tex.patch2: trivial rewording of docs for clarity. 5. Backport above changes to 2.2 bugfix branch. Jeremy in CVS: > The latest changes to the redirect handler couldn't possibly have been > tested, because they did not compute a newurl and failed with a > NameError. The __name__ == "__main__": block has a test for > redirects. Ah. The tests are preceeded by a warning about only working from a particular set of hosts: I mis-remembered, thinking that applied to *all* the tests. Sorry. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 01:14 Message: Logged In: YES user_id=261020 OK, I can't test IE, because Windows doesn't have a proper loopback adapter, and my Windows machine is disconnected. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 15:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 21:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 01:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 18:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 09:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 16:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 16:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 21:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 21:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 21:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 20:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Sun May 11 05:39:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 21:39:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:39 Message: Logged In: YES user_id=31435 The patch seems fines to me. I've attached a new patch, combining yours with new tests in test_class.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 14:04 Message: Logged In: YES user_id=6380 A trick similar to what we do in object_new might work. There, we raise an error if the tp_init slot is the default function (object_init) and any arguments are passed. I propose that object_hash checks that tp_compare and tp_richcompare are both NULL. I'm attaching a patch -- let me know if that works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-09 13:54 Message: Logged In: YES user_id=31435 >>> class C: # classic class complains ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} Traceback (most recent call last): File "", line 1, in ? TypeError: unhashable instance >>> class C(object): # new-style class does not complain ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} {<__main__.C object at 0x007F6970>: 1} >>> That was under current CVS. I see the same behavior in 2.2.3, so this isn't new. About Thomas's original report, I don't agree -- the default behavior is very useful. The rule I've always lived by is that, to be usable as a dict key, an instance's class must either: 1. Implement none of {__cmp__, __eq__, __hash__}. or 2. Implement __hash__ and (at least) one of {__cmp, __eq__}. Classic classes still work this way. New-style classes don't appear to outlaw any combination here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 13:44 Message: Logged In: YES user_id=6380 Yes, please paste an example here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 13:32 Message: Logged In: YES user_id=31392 Currently, a new-style class that defines __cmp__ but not __hash__ is usable as a dictionary key. That seems related to this bug. Should I paste the example here and bump the priority? Or should I open a separate bug report? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I spent an afternoon looking into this, and I can't see an easy solution. The idea of only inheriting __hash__ together with certain other slots is really flawed; it may be better if object DIDN'T define a default implementation for __hash__, comparisons (both flavors), and other things, or maybe the default __hash__ should raise an exception when the comparisons are not those inherited from object, or maybe PyType_Ready should insert a dummy __hash__ when it sees that you redefine __eq__, or... I really don't know. I'm going to sleep on this some more, and lower the priority. You can always get the right behavior by explicitly defining __hash__. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 13:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Sun May 11 05:52:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 10 May 2003 21:52:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-735674 ] libwinsound.tex is missing MessageBeep() description Message-ID: Bugs item #735674, was opened at 2003-05-10 07: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=735674&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: libwinsound.tex is missing MessageBeep() description Initial Comment: libwinsound.tex is missing a description of the MessageBeep() function. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:52 Message: Logged In: YES user_id=31435 Assigned to Guido because, IIRC, he added this function. Guido, why did you add it? It seems like a redundant way of calling winsound.PlaySound() with the SND_ALIAS argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 From noreply@sourceforge.net Sun May 11 11:16:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 03:16:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:16 Message: Logged In: YES user_id=6380 OK, feel free to check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:39 Message: Logged In: YES user_id=31435 The patch seems fines to me. I've attached a new patch, combining yours with new tests in test_class.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 14:04 Message: Logged In: YES user_id=6380 A trick similar to what we do in object_new might work. There, we raise an error if the tp_init slot is the default function (object_init) and any arguments are passed. I propose that object_hash checks that tp_compare and tp_richcompare are both NULL. I'm attaching a patch -- let me know if that works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-09 13:54 Message: Logged In: YES user_id=31435 >>> class C: # classic class complains ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} Traceback (most recent call last): File "", line 1, in ? TypeError: unhashable instance >>> class C(object): # new-style class does not complain ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} {<__main__.C object at 0x007F6970>: 1} >>> That was under current CVS. I see the same behavior in 2.2.3, so this isn't new. About Thomas's original report, I don't agree -- the default behavior is very useful. The rule I've always lived by is that, to be usable as a dict key, an instance's class must either: 1. Implement none of {__cmp__, __eq__, __hash__}. or 2. Implement __hash__ and (at least) one of {__cmp, __eq__}. Classic classes still work this way. New-style classes don't appear to outlaw any combination here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 13:44 Message: Logged In: YES user_id=6380 Yes, please paste an example here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 13:32 Message: Logged In: YES user_id=31392 Currently, a new-style class that defines __cmp__ but not __hash__ is usable as a dictionary key. That seems related to this bug. Should I paste the example here and bump the priority? Or should I open a separate bug report? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I spent an afternoon looking into this, and I can't see an easy solution. The idea of only inheriting __hash__ together with certain other slots is really flawed; it may be better if object DIDN'T define a default implementation for __hash__, comparisons (both flavors), and other things, or maybe the default __hash__ should raise an exception when the comparisons are not those inherited from object, or maybe PyType_Ready should insert a dummy __hash__ when it sees that you redefine __eq__, or... I really don't know. I'm going to sleep on this some more, and lower the priority. You can always get the right behavior by explicitly defining __hash__. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 13:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Sun May 11 11:21:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 03:21:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-735674 ] libwinsound.tex is missing MessageBeep() description Message-ID: Bugs item #735674, was opened at 2003-05-10 07:44 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: libwinsound.tex is missing MessageBeep() description Initial Comment: libwinsound.tex is missing a description of the MessageBeep() function. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:21 Message: Logged In: YES user_id=6380 I added it because I discovered that on my Win98 machine certain calls to MessageBeep() make a funny sound (a very brief distorted click) rather than what they are supposed to do. I haven't found docs showing the resource names used by MessageBeep() that I could pass to SND_ALIAS. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:52 Message: Logged In: YES user_id=31435 Assigned to Guido because, IIRC, he added this function. Guido, why did you add it? It seems like a redundant way of calling winsound.PlaySound() with the SND_ALIAS argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 From noreply@sourceforge.net Sun May 11 14:41:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 06:41:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 09:41 Message: Logged In: YES user_id=6380 Oops, not so fast. This also makes object.__hash__() calls fail when it is explicitly invoked, e.g. when a class overrides __eq__ to print a message and then call the base class __eq__, it must do the same for __hash__, but object.__hash__ will still fail in this case. I'll think of a fix for that. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:16 Message: Logged In: YES user_id=6380 OK, feel free to check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:39 Message: Logged In: YES user_id=31435 The patch seems fines to me. I've attached a new patch, combining yours with new tests in test_class.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 14:04 Message: Logged In: YES user_id=6380 A trick similar to what we do in object_new might work. There, we raise an error if the tp_init slot is the default function (object_init) and any arguments are passed. I propose that object_hash checks that tp_compare and tp_richcompare are both NULL. I'm attaching a patch -- let me know if that works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-09 13:54 Message: Logged In: YES user_id=31435 >>> class C: # classic class complains ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} Traceback (most recent call last): File "", line 1, in ? TypeError: unhashable instance >>> class C(object): # new-style class does not complain ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} {<__main__.C object at 0x007F6970>: 1} >>> That was under current CVS. I see the same behavior in 2.2.3, so this isn't new. About Thomas's original report, I don't agree -- the default behavior is very useful. The rule I've always lived by is that, to be usable as a dict key, an instance's class must either: 1. Implement none of {__cmp__, __eq__, __hash__}. or 2. Implement __hash__ and (at least) one of {__cmp, __eq__}. Classic classes still work this way. New-style classes don't appear to outlaw any combination here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 13:44 Message: Logged In: YES user_id=6380 Yes, please paste an example here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 13:32 Message: Logged In: YES user_id=31392 Currently, a new-style class that defines __cmp__ but not __hash__ is usable as a dictionary key. That seems related to this bug. Should I paste the example here and bump the priority? Or should I open a separate bug report? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I spent an afternoon looking into this, and I can't see an easy solution. The idea of only inheriting __hash__ together with certain other slots is really flawed; it may be better if object DIDN'T define a default implementation for __hash__, comparisons (both flavors), and other things, or maybe the default __hash__ should raise an exception when the comparisons are not those inherited from object, or maybe PyType_Ready should insert a dummy __hash__ when it sees that you redefine __eq__, or... I really don't know. I'm going to sleep on this some more, and lower the priority. You can always get the right behavior by explicitly defining __hash__. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 13:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Sun May 11 17:03:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 09:03:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-735674 ] libwinsound.tex is missing MessageBeep() description Message-ID: Bugs item #735674, was opened at 2003-05-10 07: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=735674&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: libwinsound.tex is missing MessageBeep() description Initial Comment: libwinsound.tex is missing a description of the MessageBeep() function. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-11 12:03 Message: Logged In: YES user_id=31435 I don't think you meant what you wrote -- that you added MessageBeep() because MessageBeep() doesn't do what it's supposed to do. If PlaySound() gave a distorted click, and you're using it right, then you probably have a corrupt .wav file associated with the sound you tried to play; you can check that more directly via the Sounds applet in Control Panel (which lists the .wav file associated with sound names, and has a preview button to play them directly). About docs, did you read the Python docs for PlaySound ()? For example, MessageBeep(MB_ICONASTERISK) should do the same as PlaySound('SystemAsterisk', SND_ALIAS) The docs don't directly list MB_XYZ equivalents, but they're easy to guess from the Python docs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:21 Message: Logged In: YES user_id=6380 I added it because I discovered that on my Win98 machine certain calls to MessageBeep() make a funny sound (a very brief distorted click) rather than what they are supposed to do. I haven't found docs showing the resource names used by MessageBeep() that I could pass to SND_ALIAS. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:52 Message: Logged In: YES user_id=31435 Assigned to Guido because, IIRC, he added this function. Guido, why did you add it? It seems like a redundant way of calling winsound.PlaySound() with the SND_ALIAS argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 From noreply@sourceforge.net Sun May 11 21:40:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 13:40:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-735674 ] libwinsound.tex is missing MessageBeep() description Message-ID: Bugs item #735674, was opened at 2003-05-10 07:44 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: libwinsound.tex is missing MessageBeep() description Initial Comment: libwinsound.tex is missing a description of the MessageBeep() function. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 16:40 Message: Logged In: YES user_id=6380 I really did mean what I wrote -- I wanted to experiment with different calls to MessageBeep() to see how far the damage extends. I tried the control panel and none of the sounds there are broken -- yet MessageBeep() is broken. We can look at this tomorrow in the office (my laptop is turned off right now and I have no time for experiments). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 12:03 Message: Logged In: YES user_id=31435 I don't think you meant what you wrote -- that you added MessageBeep() because MessageBeep() doesn't do what it's supposed to do. If PlaySound() gave a distorted click, and you're using it right, then you probably have a corrupt .wav file associated with the sound you tried to play; you can check that more directly via the Sounds applet in Control Panel (which lists the .wav file associated with sound names, and has a preview button to play them directly). About docs, did you read the Python docs for PlaySound ()? For example, MessageBeep(MB_ICONASTERISK) should do the same as PlaySound('SystemAsterisk', SND_ALIAS) The docs don't directly list MB_XYZ equivalents, but they're easy to guess from the Python docs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:21 Message: Logged In: YES user_id=6380 I added it because I discovered that on my Win98 machine certain calls to MessageBeep() make a funny sound (a very brief distorted click) rather than what they are supposed to do. I haven't found docs showing the resource names used by MessageBeep() that I could pass to SND_ALIAS. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:52 Message: Logged In: YES user_id=31435 Assigned to Guido because, IIRC, he added this function. Guido, why did you add it? It seems like a redundant way of calling winsound.PlaySound() with the SND_ALIAS argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 From noreply@sourceforge.net Sun May 11 21:40:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 13:40:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-735274 ] FILEMODE not honoured Message-ID: Bugs item #735274, was opened at 2003-05-09 17:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735274&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: FILEMODE not honoured Initial Comment: The Python build process doesn't honour the FILEMODE setting in Makefile.pre.in (or passed in at install time with "make FILEMODE=664 install") because configure sets the install command to an explicit "${INSTALL} -m 644" in stead of to "${INSTALL} -m ${FILEMODE}". DIRMODE and EXEMODE are handled correctly. Please let me know whether you agree and assign back to me, if you agree I'll put the changes in. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 22:40 Message: Logged In: YES user_id=21627 I'm probably missing something: Where precisely is EXEMODE being used? As for FILEMODE: Is it important that this is honored? Users wanting to override this can also override INSTALL_DATA instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735274&group_id=5470 From noreply@sourceforge.net Sun May 11 21:42:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 13:42:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-702157 ] No documentation of static/dynamic python modules. Message-ID: Bugs item #702157, was opened at 2003-03-12 13:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation of static/dynamic python modules. Initial Comment: Hi, This problem cost me very much time to solve: After I build Python, all dynamic libraries got dynamically linked into the Python interpreter (libraries like zlib and tcl/tk stuff). I coudn't find out why this is, I only want to load zlib.so when I do a "import zlib" and not when I start Python. And this is (I think) the difference between statically and dynamically build Python libraries, but this isn't explaind in a clear way. You can configure the dynamic/static module beheviour in the Modules/Setup file (afher you did a configure) with the *shared* flag. The dinamic/static module behaviour should at least very clear described in that file, this is not the case at this moment. Best regards, Jan ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 22:42 Message: Logged In: YES user_id=21627 Closing this because of lack of feedback. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 19:51 Message: Logged In: YES user_id=21627 I cannot reproduce this. If I leave # *shared*, but enable zlib in Modules/Setup, I get no file Modules/zlib.so, only Modules/zlib.o. This is incorporated into python. If I also leave zlib commented in Modules/Setup, zlib.so is build through setup.py in build/lib-somewhere, *after* python was linked. Can you provide a complete build log? ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 13:02 Message: Logged In: YES user_id=732192 Hi, When I build python with zlib and the commented shared flag "#*shared*". then zlib.so is included in ./python (checked with ldd ./python). When I build python with zlib and the *shared* flag commented out then is zlib.so not part of the ./python program. The question is now: is this the difference between shared and static modules? or do I have so weird problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:29 Message: Logged In: YES user_id=21627 What do you mean when you say "all dynamic libraries got dynamically linked into the Python interpreter"? If it means what I understand it means (i.e. all libraries are passed to the ld command creating the python binary), then this is not supposed to happen. Can you provide a make log to demonstrate this more clearly? ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-13 14:05 Message: Logged In: YES user_id=732192 Uuuh when I say "python library" I mean a "python module" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 From noreply@sourceforge.net Mon May 12 00:03:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:03:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-735674 ] libwinsound.tex is missing MessageBeep() description Message-ID: Bugs item #735674, was opened at 2003-05-10 07: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=735674&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: libwinsound.tex is missing MessageBeep() description Initial Comment: libwinsound.tex is missing a description of the MessageBeep() function. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-11 19:03 Message: Logged In: YES user_id=31435 Hmm. OK. There's a disconnect here somewhere. Like why would you add a function to Python when you don't think it works correctly? I understand wanting to experiment on your own box. If it doesn't work, though, why add it to the distribution? FWIW, the 5 MB_xyz thingies work OK with MessageBeep () on my Win98SE laptop. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 16:40 Message: Logged In: YES user_id=6380 I really did mean what I wrote -- I wanted to experiment with different calls to MessageBeep() to see how far the damage extends. I tried the control panel and none of the sounds there are broken -- yet MessageBeep() is broken. We can look at this tomorrow in the office (my laptop is turned off right now and I have no time for experiments). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 12:03 Message: Logged In: YES user_id=31435 I don't think you meant what you wrote -- that you added MessageBeep() because MessageBeep() doesn't do what it's supposed to do. If PlaySound() gave a distorted click, and you're using it right, then you probably have a corrupt .wav file associated with the sound you tried to play; you can check that more directly via the Sounds applet in Control Panel (which lists the .wav file associated with sound names, and has a preview button to play them directly). About docs, did you read the Python docs for PlaySound ()? For example, MessageBeep(MB_ICONASTERISK) should do the same as PlaySound('SystemAsterisk', SND_ALIAS) The docs don't directly list MB_XYZ equivalents, but they're easy to guess from the Python docs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:21 Message: Logged In: YES user_id=6380 I added it because I discovered that on my Win98 machine certain calls to MessageBeep() make a funny sound (a very brief distorted click) rather than what they are supposed to do. I haven't found docs showing the resource names used by MessageBeep() that I could pass to SND_ALIAS. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:52 Message: Logged In: YES user_id=31435 Assigned to Guido because, IIRC, he added this function. Guido, why did you add it? It seems like a redundant way of calling winsound.PlaySound() with the SND_ALIAS argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 From noreply@sourceforge.net Mon May 12 00:41:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:41:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-429193 ] CGIHTTPServer crashes Explorer in WinME Message-ID: Bugs item #429193, was opened at 2001-05-31 17:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=429193&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer crashes Explorer in WinME Initial Comment: Python Versions: BeOpen 2.0 & ActiveState Python 2.1 Windows Version: Windows Millenium Edition PC: Dell Inspiron 8000 Laptop Issue: Invoking CGIHTTPServer.py either by itself or subclassed leads to critical problems when serving CGI content (*.py) CGIHTTPServer will serve HTML with no issues. If a CGI link is clicked, Windows sounds "critical stop" system sound, the console shows that the CGI is being called ("C:\>Python.exe -u foo.py") and will hang Internet Explorer 5.5 CGIHTTPServer cannot, at that point, be killed through Ctrl-C. If the console Window is simply closed, Windows will cause Explorer to sometimes crash, preventing a clean shutdown of the machine. This problem exists even if "#!C:\Python20\Python.exe" is included as first line of CGI, and if w9xpopen is included in the CGI directory. Problem does not exist with Apache or Xitami servers calling Python CGI scripts. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:41 Message: Logged In: YES user_id=357491 Does anyone have a copy of Python 2.1 or Python 2.0 on a Windows box to test this? If not shouldn't we close this as out of date? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=429193&group_id=5470 From noreply@sourceforge.net Mon May 12 00:53:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:53:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-429193 ] CGIHTTPServer crashes Explorer in WinME Message-ID: Bugs item #429193, was opened at 2001-05-31 20:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=429193&group_id=5470 Category: Windows >Group: Platform-specific >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) Summary: CGIHTTPServer crashes Explorer in WinME Initial Comment: Python Versions: BeOpen 2.0 & ActiveState Python 2.1 Windows Version: Windows Millenium Edition PC: Dell Inspiron 8000 Laptop Issue: Invoking CGIHTTPServer.py either by itself or subclassed leads to critical problems when serving CGI content (*.py) CGIHTTPServer will serve HTML with no issues. If a CGI link is clicked, Windows sounds "critical stop" system sound, the console shows that the CGI is being called ("C:\>Python.exe -u foo.py") and will hang Internet Explorer 5.5 CGIHTTPServer cannot, at that point, be killed through Ctrl-C. If the console Window is simply closed, Windows will cause Explorer to sometimes crash, preventing a clean shutdown of the machine. This problem exists even if "#!C:\Python20\Python.exe" is included as first line of CGI, and if w9xpopen is included in the CGI directory. Problem does not exist with Apache or Xitami servers calling Python CGI scripts. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-11 19:53 Message: Logged In: YES user_id=31435 I have 2.1.3 and Win98SE and Win2K, but don't know how to go about trying to reproduce the problem. I don't have IE 5.5 or WinME. Since nobody else has picked this up in the last 2 years, or reported a similar problem again, I'm indeed closing it as out-of-date. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 19:41 Message: Logged In: YES user_id=357491 Does anyone have a copy of Python 2.1 or Python 2.0 on a Windows box to test this? If not shouldn't we close this as out of date? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=429193&group_id=5470 From noreply@sourceforge.net Mon May 12 00:54:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:54:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-437472 ] MacPy21: sre "recursion limit" bug Message-ID: Bugs item #437472, was opened at 2001-06-29 14:50 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 Category: Regular Expressions Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Brett Cannon (bcannon) Summary: MacPy21: sre "recursion limit" bug Initial Comment: As of Python 2.0, the sre module had bug wherein a "RuntimeError: maximum recursion limit exceeded" would be raised whenever an expression matched something on the order of 16,000+ characters. The bug, nominally fixed in time for Python 2.1, is still present in MacPython 2.1, as evidenced by the following transcript copied from an interactive session with the interpreter. Note success with pre module, however. It makes me curious, since the bug appears to be fixed in WinPython 2.1, whether the correct source was used when compiling MacPython 2.1.... ========== Python 2.1 (#92, Apr 24 2001, 23:59:23) [CW PPC GUSI2 THREADS] on mac >>> import sre, pre, string >>> l = ["XXX", "%"*20000, "XXX"] >>> sre_regex = sre.compile(r"XXX.*?XXX") >>> match_object = sre_regex.search(string.join(l)) Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ### Above error first reported upon release of sre with Python 2.0 ### >>> ### Bug supposedly fixed in Python 2.0.1 release (no Mac version, I know) ### >>> pre_regex = pre.compile(r"XXX.*XXX") >>> match_object = pre_regex.search(string.join(l)) >>> match_object >>> ### Note above success with pre module instead of sre ### >>> ### Wrong sre module source used when compiling MacPython 2.1? ### ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:54 Message: Logged In: YES user_id=357491 I agree with Gary (herron); this is not a bug but a limitation of the system and the re module. I am closing this bug as invalid. ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-05-04 23:46 Message: Logged In: YES user_id=395736 This was not a bug, but rather a limitation of the sre engine. That limitation has now been removed (for simple used of "*?" as seen here) in Python 2.3beta1. ---------------------------------------------------------------------- Comment By: Gary Herron (herron) Date: 2003-05-04 10:49 Message: Logged In: YES user_id=395736 This was not a bug, but rather a limitation of the sre engine. That limitation has now been removed (for simple used of "*?" as seen here) in Python 2.3beta1. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-07-02 01:58 Message: Logged In: YES user_id=45365 When I try this in a MacPython build from the CVS repository the sre example does not crash, but match_object ends up as None. Also not the behaviour I expect... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 From noreply@sourceforge.net Mon May 12 00:55:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:55:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-444514 ] raw-unicode-escape codec fails roundtrip Message-ID: Bugs item #444514, was opened at 2001-07-25 09:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 3 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: raw-unicode-escape codec fails roundtrip Initial Comment: On wide Python builds, the raw-unicode-escape codec fails the round-trip for non-BMP code points. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:55 Message: Logged In: YES user_id=357491 Marc-Andre, is this bug still unresolved? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 03:47 Message: Logged In: YES user_id=38388 I'll look into this after I'm back from vacation on the 10.09. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 From noreply@sourceforge.net Mon May 12 00:57:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 16:57:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-735674 ] libwinsound.tex is missing MessageBeep() description Message-ID: Bugs item #735674, was opened at 2003-05-10 07: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=735674&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: libwinsound.tex is missing MessageBeep() description Initial Comment: libwinsound.tex is missing a description of the MessageBeep() function. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-11 19:57 Message: Logged In: YES user_id=31435 FYI, the MB_xyz thingies work OK with MessageBeep () on my Win98SE desktop too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 19:03 Message: Logged In: YES user_id=31435 Hmm. OK. There's a disconnect here somewhere. Like why would you add a function to Python when you don't think it works correctly? I understand wanting to experiment on your own box. If it doesn't work, though, why add it to the distribution? FWIW, the 5 MB_xyz thingies work OK with MessageBeep () on my Win98SE laptop. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 16:40 Message: Logged In: YES user_id=6380 I really did mean what I wrote -- I wanted to experiment with different calls to MessageBeep() to see how far the damage extends. I tried the control panel and none of the sounds there are broken -- yet MessageBeep() is broken. We can look at this tomorrow in the office (my laptop is turned off right now and I have no time for experiments). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 12:03 Message: Logged In: YES user_id=31435 I don't think you meant what you wrote -- that you added MessageBeep() because MessageBeep() doesn't do what it's supposed to do. If PlaySound() gave a distorted click, and you're using it right, then you probably have a corrupt .wav file associated with the sound you tried to play; you can check that more directly via the Sounds applet in Control Panel (which lists the .wav file associated with sound names, and has a preview button to play them directly). About docs, did you read the Python docs for PlaySound ()? For example, MessageBeep(MB_ICONASTERISK) should do the same as PlaySound('SystemAsterisk', SND_ALIAS) The docs don't directly list MB_XYZ equivalents, but they're easy to guess from the Python docs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:21 Message: Logged In: YES user_id=6380 I added it because I discovered that on my Win98 machine certain calls to MessageBeep() make a funny sound (a very brief distorted click) rather than what they are supposed to do. I haven't found docs showing the resource names used by MessageBeep() that I could pass to SND_ALIAS. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:52 Message: Logged In: YES user_id=31435 Assigned to Guido because, IIRC, he added this function. Guido, why did you add it? It seems like a redundant way of calling winsound.PlaySound() with the SND_ALIAS argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 From noreply@sourceforge.net Mon May 12 01:28:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 17:28:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-735535 ] cStringIO.StringIO Message-ID: Bugs item #735535, was opened at 2003-05-09 21:49 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735535&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO.StringIO Initial Comment: Instance of cStringIO.StringIO have no __class__ attribute. Other built-in types, such as cPickle.Pickler, do. ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2003-05-11 20:28 Message: Logged In: YES user_id=366566 2.2, apparently, though I thought I was using 2.3 at the time ;) My mistake. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-09 23:59 Message: Logged In: YES user_id=80475 Which version are you using? I don't see the same thing: >>> a = cStringIO.StringIO('the quick') >>> type(a) >>> a.__class__ >>> b = cStringIO.StringIO() >>> type(b) >>> b.__class__ >>> dir(a) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__h ash__', '__init__', '__iter__', '__new__', '__reduce__', '__redu ce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'flush', 'g etvalue', 'isatty', 'next', 'read', 'readline', 'readlines', 'reset', ' seek', 'tell', 'truncate'] >>> dir(b) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__h ash__', '__init__', '__iter__', '__new__', '__reduce__', '__redu ce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'flush', 'g etvalue', 'isatty', 'next', 'read', 'readline', 'readlines', 'reset', ' seek', 'softspace', 'tell', 'truncate', 'write', 'writelines'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735535&group_id=5470 From noreply@sourceforge.net Mon May 12 01:29:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 17:29:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-735535 ] cStringIO.StringIO Message-ID: Bugs item #735535, was opened at 2003-05-09 21:49 Message generated for change (Settings changed) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735535&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO.StringIO Initial Comment: Instance of cStringIO.StringIO have no __class__ attribute. Other built-in types, such as cPickle.Pickler, do. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-05-11 20:28 Message: Logged In: YES user_id=366566 2.2, apparently, though I thought I was using 2.3 at the time ;) My mistake. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-09 23:59 Message: Logged In: YES user_id=80475 Which version are you using? I don't see the same thing: >>> a = cStringIO.StringIO('the quick') >>> type(a) >>> a.__class__ >>> b = cStringIO.StringIO() >>> type(b) >>> b.__class__ >>> dir(a) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__h ash__', '__init__', '__iter__', '__new__', '__reduce__', '__redu ce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'flush', 'g etvalue', 'isatty', 'next', 'read', 'readline', 'readlines', 'reset', ' seek', 'tell', 'truncate'] >>> dir(b) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__h ash__', '__init__', '__iter__', '__new__', '__reduce__', '__redu ce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'flush', 'g etvalue', 'isatty', 'next', 'read', 'readline', 'readlines', 'reset', ' seek', 'softspace', 'tell', 'truncate', 'write', 'writelines'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735535&group_id=5470 From noreply@sourceforge.net Mon May 12 01:35:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 17:35:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-450225 ] urljoin fails RFC tests Message-ID: Bugs item #450225, was opened at 2001-08-11 22:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: urljoin fails RFC tests Initial Comment: I've put together a test suite for Python's URLparse module, based on the tests in Appendix C of RFC2396 (the URI RFC). They're available at: http://lists.w3.org/Archives/Public/uri/2001Aug/ 0013.html The major problem seems to be that it treats queries and parameters as special components (not just normal parts of the path), making this related to: http://sourceforge.net/tracker/?group_id=5470& atid=105470&func=detail&aid=210834 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-11 17:35 Message: Logged In: YES user_id=357491 mbrierst is right. From C.1 of RFC 2396 (with http://a/b/c/d;p?q as the base): ?y = http://a/b/c/?y ;x = http://a/b/c/;x And notice how this contradicts RFC 1808 ( with as the base): ?y = ;x = So obviously there is a conflict here. And since RFC 2396 says "it revises and replaces the generic definitions in RFC 1738 and RFC 1808" (of which "generic" just means the actual syntax) this means that RFC 2396's solution should override. Now the issue is whether the patch for this is the right thing to do (I am ignoring if the patch is correct; have not tested it yet). This shouldn't break anything since the whole point of urlparse.urljoin is to have an abstracted way to create URIs without the user having to worry about all of these rules. So I say that it should be changed. Fred, do you mind if I reassign this patch to myself and deal with it? ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-03 13:02 Message: Logged In: YES user_id=670441 The two failing tests could not pass because RFC 1808 and RFC 2396 seem to conflict when a relative URI is given as just ;y or just ?y. RFC 2396 claims to update RFC 1808, so presumably it describes the correct behavior. The patch in this message (I can't upload it on sourceforge here for some reason) brings urljoin's behavior in line with RFC 2396, and changes the appropriate test cases. I think if you apply this patch this bug can be closed. Let me know what you think Index: python/dist/src/Lib/urlparse.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/urlparse.py,v retrieving revision 1.39 diff -c -r1.39 urlparse.py *** python/dist/src/Lib/urlparse.py 7 Jan 2003 02:09:16 -0000 1.39 --- python/dist/src/Lib/urlparse.py 3 Feb 2003 20:51:08 -0000 *************** *** 157,169 **** if path[:1] == '/': return urlunparse((scheme, netloc, path, params, query, fragment)) ! if not path: ! if not params: ! params = bparams ! if not query: ! query = bquery return urlunparse((scheme, netloc, bpath, ! params, query, fragment)) segments = bpath.split('/')[:-1] + path.split('/') # XXX The stuff below is bogus in various ways... if segments[-1] == '.': --- 157,165 ---- if path[:1] == '/': return urlunparse((scheme, netloc, path, params, query, fragment)) ! if not (path or params or query): return urlunparse((scheme, netloc, bpath, ! bparams, bquery, fragment)) segments = bpath.split('/')[:-1] + path.split('/') # XXX The stuff below is bogus in various ways... if segments[-1] == '.': Index: python/dist/src/Lib/test/test_urlparse.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_urlparse.py,v retrieving revision 1.11 diff -c -r1.11 test_urlparse.py *** python/dist/src/Lib/test/test_urlparse.py 6 Jan 2003 20:27:03 -0000 1.11 --- python/dist/src/Lib/test/test_urlparse.py 3 Feb 2003 20:51:12 -0000 *************** *** 54,59 **** --- 54,63 ---- self.assertEqual(urlparse.urlunparse(urlparse.urlparse(u)), u) def test_RFC1808(self): + # updated by RFC 2396 + # self.checkJoin(RFC1808_BASE, '?y', 'http://a/b/c/d;p?y') + # self.checkJoin(RFC1808_BASE, ';x', 'http://a/b/c/d;x') + # "normal" cases from RFC 1808: self.checkJoin(RFC1808_BASE, 'g:h', 'g:h') self.checkJoin(RFC1808_BASE, 'g', 'http://a/b/c/g') *************** *** 61,74 **** self.checkJoin(RFC1808_BASE, 'g/', 'http://a/b/c/g/') self.checkJoin(RFC1808_BASE, '/g', 'http://a/g') self.checkJoin(RFC1808_BASE, '//g', 'http://g') - self.checkJoin(RFC1808_BASE, '?y', 'http://a/b/c/d;p?y') self.checkJoin(RFC1808_BASE, 'g?y', 'http://a/b/c/g?y') self.checkJoin(RFC1808_BASE, 'g?y/./x', 'http://a/b/c/g?y/./x') self.checkJoin(RFC1808_BASE, '#s', 'http://a/b/c/d;p?q#s') self.checkJoin(RFC1808_BASE, 'g#s', 'http://a/b/c/g#s') self.checkJoin(RFC1808_BASE, 'g#s/./x', 'http://a/b/c/g#s/./x') self.checkJoin(RFC1808_BASE, 'g?y#s', 'http://a/b/c/g?y#s') - self.checkJoin(RFC1808_BASE, ';x', 'http://a/b/c/d;x') self.checkJoin(RFC1808_BASE, 'g;x', 'http://a/b/c/g;x') self.checkJoin(RFC1808_BASE, 'g;x?y#s', 'http://a/b/c/g;x?y#s') self.checkJoin(RFC1808_BASE, '.', 'http://a/b/c/') --- 65,76 ---- *************** *** 103,111 **** def test_RFC2396(self): # cases from RFC 2396 ! ### urlparse.py as of v 1.32 fails on these two ! #self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/?y') ! #self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/;x') self.checkJoin(RFC2396_BASE, 'g:h', 'g:h') self.checkJoin(RFC2396_BASE, 'g', 'http://a/b/c/g') --- 105,113 ---- def test_RFC2396(self): # cases from RFC 2396 ! # conflict with RFC 1808, tests commented out there ! self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/?y') ! self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/;x') self.checkJoin(RFC2396_BASE, 'g:h', 'g:h') self.checkJoin(RFC2396_BASE, 'g', 'http://a/b/c/g') ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-22 21:34 Message: Logged In: YES user_id=44345 added Aaron's RFC 2396 tests to test_urlparse.py version 1.4 - the two failing tests are commented out ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-03-18 06:22 Message: Logged In: YES user_id=76089 I think it would be better btw if '..' components taking you 'off the top' were stripped. RFC 2396 says this is valid behaviour, and it's what 'real' browsers do. i.e. http://a/b/ + ../../../d == http://a/d ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2001-11-05 10:34 Message: Logged In: YES user_id=122141 Oops, meant to attach it... ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2001-11-05 10:30 Message: Logged In: YES user_id=122141 Sure, here they are: import urlparse base = 'http://a/b/c/d;p?q' assert urlparse.urljoin(base, 'g:h') == 'g:h' assert urlparse.urljoin(base, 'g') == 'http://a/b/c/g' assert urlparse.urljoin(base, './g') == 'http://a/b/c/g' assert urlparse.urljoin(base, 'g/') == 'http://a/b/c/g/' assert urlparse.urljoin(base, '/g') == 'http://a/g' assert urlparse.urljoin(base, '//g') == 'http://g' assert urlparse.urljoin(base, '?y') == 'http://a/b/c/?y' assert urlparse.urljoin(base, 'g?y') == 'http://a/b/c/g?y' assert urlparse.urljoin(base, '#s') == 'http://a/b/c/ d;p?q#s' assert urlparse.urljoin(base, 'g#s') == 'http://a/b/c/g#s' assert urlparse.urljoin(base, 'g?y#s') == 'http://a/b/c/ g?y#s' assert urlparse.urljoin(base, ';x') == 'http://a/b/c/;x' assert urlparse.urljoin(base, 'g;x') == 'http://a/b/c/g;x' assert urlparse.urljoin(base, 'g;x?y#s') == 'http://a/b/c/ g;x?y#s' assert urlparse.urljoin(base, '.') == 'http://a/b/c/' assert urlparse.urljoin(base, './') == 'http://a/b/c/' assert urlparse.urljoin(base, '..') == 'http://a/b/' assert urlparse.urljoin(base, '../') == 'http://a/b/' assert urlparse.urljoin(base, '../g') == 'http://a/b/g' assert urlparse.urljoin(base, '../..') == 'http://a/' assert urlparse.urljoin(base, '../../') == 'http://a/' assert urlparse.urljoin(base, '../../g') == 'http://a/g' assert urlparse.urljoin(base, '') == base assert urlparse.urljoin(base, '../../../g') == 'http://a/../g' assert urlparse.urljoin(base, '../../../../g') == 'http://a/../../g' assert urlparse.urljoin(base, '/./g') == 'http://a/./g' assert urlparse.urljoin(base, '/../g') == 'http://a/../g' assert urlparse.urljoin(base, 'g.') == 'http://a/b/c/ g.' assert urlparse.urljoin(base, '.g') == 'http://a/b/c/ .g' assert urlparse.urljoin(base, 'g..') == 'http://a/b/c/ g..' assert urlparse.urljoin(base, '..g') == 'http://a/b/c/ ..g' assert urlparse.urljoin(base, './../g') == 'http://a/b/g' assert urlparse.urljoin(base, './g/.') == 'http://a/b/c/ g/' assert urlparse.urljoin(base, 'g/./h') == 'http://a/b/c/ g/h' assert urlparse.urljoin(base, 'g/../h') == 'http://a/b/c/ h' assert urlparse.urljoin(base, 'g;x=1/./y') == 'http://a/b/c/g;x=1/y' assert urlparse.urljoin(base, 'g;x=1/../y') == 'http://a/b/ c/y' assert urlparse.urljoin(base, 'g?y/./x') == 'http://a/b/c/g?y/./x' assert urlparse.urljoin(base, 'g?y/../x') == 'http://a/b/c/g?y/../x' assert urlparse.urljoin(base, 'g#s/./x') == 'http://a/b/ c/g#s/./x' assert urlparse.urljoin(base, 'g#s/../x') == 'http://a/b/ c/g#s/../x' ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-05 10:05 Message: Logged In: YES user_id=3066 This looks like its probably related to #478038; I'll try to tackle them together. Can you attach your tests to the bug report on SF? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470 From noreply@sourceforge.net Mon May 12 07:36:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 11 May 2003 23:36:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-458447 ] New httplib lacks documentation Message-ID: Bugs item #458447, was opened at 2001-09-04 10:01 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=458447&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Fixed Priority: 6 Submitted By: Rich Salz (rsalz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: New httplib lacks documentation Initial Comment: urllib should allow the user to set the content-type. This would allow applications to do more than just "forms posting" -- e.g., use it to make SOAP requests. The attached patch allows that. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-11 23:36 Message: Logged In: YES user_id=357491 It looks like the parameters to HTTPSConnection have changed and are now ``def __init__(self, host, port=None, key_file=None, cert_file=None, strict=None):``. The docs on the key file and cert file can probably be copied from socket.ssl . ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-12-18 09:34 Message: Logged In: YES user_id=36737 The **x509 parameter of HTTPSConnection needs to be documented. It's a dictionary with at most two keys. key_file specifies the PEM-fformat private key file and cert_file specifies contains the PEM-format certificate and optional list of CA's in the cert chain. (I believe there's an open defect for SSL sockets not being docuemented.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-29 22:07 Message: Logged In: YES user_id=3066 Checked in as Doc/lib/libhttplib.tex revision 1.28. Updates contributed by Kalle Svensson. Thanks, Kalle! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-26 13:51 Message: Logged In: YES user_id=3066 I have contributed docs for the new version waiting for review in my inbox; these should be checked in this week. Bumping priority so this stays visible to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:37 Message: Logged In: YES user_id=6380 Fred: it turns out the httplib docs still document the old version of the module. The new version is considerably more powerful, and is essentially undocumented. Maybe you can shame Greg Stein into providing some docs, or maybe you can convert the copious docstrings to LaTeX. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-09-04 20:45 Message: Logged In: YES user_id=44345 I'm not sure why you'd want to program SOAP (or XMLRPC, for that matter) directly. You would (normally) only use those protocols through special-purpose modules like SOAP.py or xmlrpclib.py, both of which talk to httplib I believe. I don't see that allowing the Content-Type: header to be overridden at the urllib level is all that necessary. If you're going to want to mess with Content-Type: you're probably going to want to mess with other headers as well. ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-09-04 19:02 Message: Logged In: YES user_id=36737 I created this bug because urllib didn't let you set the content-type header. Guido pointed out that I should be using httplib. I didn't use httplib because I didn't know until I read the source, that httplib had an https object that used SSL. So I guess "document the https object" is what this has mutated into. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 14:03 Message: Logged In: YES user_id=3066 It's not at all clear what sort of documentation update is needed. What did you have in mind? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 12:20 Message: Logged In: YES user_id=6380 Please don't Delete requests. Please don't Close them unless you are a project manager (I consider it a SF bug that the submitter can decide to close a bug report if they happen to have admin perms on another project). I've reopened this and recategorized as Doc and assigned to Fred so he can see if the httplib docs need to be updated. ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-09-04 12:16 Message: Logged In: YES user_id=36737 Okay, I'll accept that. Had HTTP documented that it included HTTPS I wouldn't have made the initial mistake. :) Let me know if you want the diff. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:20 Message: Logged In: YES user_id=6380 Isn't SOAP an HTTP application? Then you shouldn't be using urllib, but httplib. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:20 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=458447&group_id=5470 From noreply@sourceforge.net Mon May 12 08:35:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 00:35:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-675928 ] Have exception arguments keep their type Message-ID: Bugs item #675928, was opened at 2003-01-27 22:06 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Have exception arguments keep their type Initial Comment: If you execute the following code:: try: raise Exception('a string') except Exception, err: print type(err) it prints out that ``err`` is a type 'instance'. It would be nice if it returned the type of the actual argument (in this case, type 'str'). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 00:35 Message: Logged In: YES user_id=357491 Forgot to mention that I opened patch #726751 to try to clarify. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-25 15:24 Message: Logged In: YES user_id=357491 I played around today and discovered what was confusing me on all of this. Executing the following code:: exc = None try: raise Exception('blah') except Exception, thing: global exc; exc = thing which causes type(exc) == . But if you change the 'except' line to:: except Exception, (thing,): ... then type(exc) == . Obviously when you have a tuple as the target it is unpacking the arguments in the exception (i.e., it is just `` = ``). I just wasn't viewing it as an assignment. I guess the line "exception's parameter is assigned to the target" from the reference manual threw me; I thought it literally meant the parameters to the exception period, not only if there was assignment unpacking. So since this seems to be another case of my quirky common sense not thinking like most people, should this bug report be closed or deleted? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-28 12:57 Message: Logged In: YES user_id=357491 I must be misunderstanding how exceptions handle passed-in values at instantiation. I know you can pass in multiple values (I assume it's ``def __init__(*args, **kwargs)`` for Exception), but I was not expecting an instance type. I think I was expecting the values from ``.args`` to be unpacked and stored in the variables instead of an actual exception object to returned in there with a smart ``__str__`` method. Perhaps the docs should clarify that you receive actual copies of the exception object with its ``args`` attribute set to the argument? The tutorial, as-is, says "the except clause may specify a variable after the exception name (or list) to receive the argument's value" which suggests to me that I will get the physical argument I passed into the exception; I expected tuple unpacking of the ``args`` attribute. In other words I see why it is the way it is, but perhaps we should clarify in the tutorial that it is an exception instance storing the arguments and not the arguments themselves? And I actually used ``str(err)`` to get my code to work, although now that I know that it actually is an instance of an exception it really isn't needed since I will just test for an exception. =) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-28 07:52 Message: Logged In: YES user_id=31435 I'm a bit baffled by this, Brett: when you instantiate a class, you can pass any number of arguments to its constructor. You happened to pass a single string argument when building an instance of Exception here, but you could have passed any number of arguments. Why should the first argument be special? (Or maybe you think the last argument should be special ). Or what if you didn't pass any arguments at all? Having "the detail" bound to the instance object raised is a feature, and a major one. If you're in the habit of passing a single string to Exception directly, note that you can already get it back via doing str(err) in the "except" clause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 From noreply@sourceforge.net Mon May 12 08:37:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 00:37:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-697990 ] Document strptime limitation Message-ID: Bugs item #697990, was opened at 2003-03-05 05:48 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Brett Cannon (bcannon) Summary: Document strptime limitation Initial Comment: Python Library Reference, Chapter 6.9: strptime: Many (at least glibc 2) versions of strptime can't parse the time zone (which strftime prints with %Z). This should be mentioned as a warning in the documentation. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 00:37 Message: Logged In: YES user_id=357491 OK, so it was agreed that _strptime will become the only implementation of time.strptime if no one gripes by the time 2.3b2 rolls around. I will fix the docs when I rip out the old C code. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-07 14:31 Message: Logged In: YES user_id=357491 So, from what I remember when Guido switched off the libc usage to get more testing of _strptime Tim was in support of just moving completely over to _strptime while Guido seemed okay with it. There was no final declaration that I know of (if there was then it was rather silly to leave in the libc wrapper code). If _strptime does turn into the only implementation I will completely flesh out the docs on _strptime and its limitations (this is one of them; been debating whether it should be able to recognize UTC and GMT as timezones beyond the two the platforms tends to know). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-07 05:17 Message: Logged In: YES user_id=6656 Is 2.3 going to call the libc strptime? If we keep using Brett's, presumably this is irrelevant. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 17:37 Message: Logged In: YES user_id=357491 I will add some note, but I don't know what yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 From noreply@sourceforge.net Mon May 12 09:10:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 01:10:21 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-412227 ] explicit regular and arithmetic rshift Message-ID: Feature Requests item #412227, was opened at 2001-03-29 08:41 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=412227&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Dean Hall (dwhall) Assigned to: Nobody/Anonymous (nobody) Summary: explicit regular and arithmetic rshift Initial Comment: Currently, Python uses auto-config tests to determine if its right shift operator ">>" performs regular right shift (RRS) or arithmetic (sign-extended) right shift (ARS). Thus, Python's behavior is dependant on the C compiler. The result for most platforms, is that ">>" is ARS. This leads to some troubling statements in Python syntax: 0xffffffff >> 1 != 0xffffffffL >> 1 -1 >> 5 == -1 The result of defaulting to ARS is that creating a RRS from the ">>" operator consumes more resources than necessary. Whereas, if RRS were the default, it is quite easy to construct the ARS in python syntax: def ARShift(a,b): #bounds checking left out return ~((~a)>>b) I would like to see these things happen: 1. Make explicit operators for ARS and RRS. I've seen ">>" and ">>>" used elsewhere. 2. Make ">>" default to RRS. It will behave more like hardware. Final note: not having RRS available makes programming some algorithms such as Hamming codes and CRC difficult and inefficient. We NEED it! ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 01:10 Message: Logged In: YES user_id=357491 In Python 2.4 all hex constants will be positive so you won't have to worry about this any longer. Thus your example of the problem will no longer be an issue once Python 2.4 comes out. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2001-09-14 15:56 Message: Logged In: YES user_id=292741 I see your problem; but this would not generalize to long ints. Those have a conceptually infinite sign extension, so RRS can't ever work on negative long numbers, and is the same as ARS for positive ones. Bearing in mind that even with longs, negative numbers are generated by ~ as well as -. So you gotta '&' with a mask at some point in any case. Even if you had your RRS operation, I suspect you would only get the behaviour you want for 32-bit values. For 16-bit values, you'd have to ^0xFFFF instead of ~, anyway; which is the equivalent slowdown. A >> in C depends not on the compiler but rather the type (signedness) of the LHS; the real difference is that python doesn't have an unsigned int! It is true that all possible workarounds tend to lead to more operators in the inner loop than you want for CRCs and things. I'm thinking of starting a 'ecc' library project for py, which could have a C implementation, and thus go fast. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=412227&group_id=5470 From noreply@sourceforge.net Mon May 12 10:28:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 02:28:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-444514 ] raw-unicode-escape codec fails roundtrip Message-ID: Bugs item #444514, was opened at 2001-07-25 18:10 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 3 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: raw-unicode-escape codec fails roundtrip Initial Comment: On wide Python builds, the raw-unicode-escape codec fails the round-trip for non-BMP code points. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-05-12 11:28 Message: Logged In: YES user_id=38388 I haven't done anything in that direction and don't have the time to do now, so feel free to assign the bug report to someone else, e.g. Martin who has done most of the wide Unicode support. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 01:55 Message: Logged In: YES user_id=357491 Marc-Andre, is this bug still unresolved? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 12:47 Message: Logged In: YES user_id=38388 I'll look into this after I'm back from vacation on the 10.09. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 From noreply@sourceforge.net Mon May 12 10:28:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 02:28:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-735301 ] timeit.py doesn't see module globals Message-ID: Bugs item #735301, was opened at 2003-05-09 16:47 Message generated for change (Settings changed) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: timeit.py doesn't see module globals Initial Comment: Simple test file (save as test.py) def test(): "Stupid test function" L = [] for i in range(100): L.append(i) if __name__=='__main__': from timeit import Timer t = Timer("test()") print t.timeit() Try to run this, and the following traceback occurs: >test.py Traceback (most recent call last): File "C:\Data\graph\test.py", line 10, in ? print t.timeit() File "C:\Apps\Python\lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "", line 6, in inner NameError: global name 'test' is not defined ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2003-05-12 10:28 Message: Logged In: YES user_id=113328 If "Wont Fix" means just that, then that's OK. But for what it's worth, this change to timeit.py seems to do what I'd expect. --- timeit.py.orig 2003-05-12 10:23:55.000000000 +0100 +++ timeit.py 2003-05-12 10:24:06.000000000 +0100 @@ -115,7 +115,8 @@ self.src = src # Save for traceback display code = compile(src, dummy_src_name, "exec") ns = {} - exec code in globals(), ns + gbl = sys._getframe(1).f_globals + exec code in gbl, ns self.inner = ns["inner"] def print_exc(self, file=None): ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-09 19:22 Message: Logged In: YES user_id=44345 I added an example of this to the module documentation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 19:06 Message: Logged In: YES user_id=6380 You must import the test function from __main__ in the setup code fragment, e.g. t = Timer("test()", "from __main__ import test") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 From noreply@sourceforge.net Mon May 12 10:41:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 02:41:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-736407 ] Problem With email.MIMEText Package Message-ID: Bugs item #736407, was opened at 2003-05-12 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=105470&aid=736407&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Abel (judasiscariot) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470 From noreply@sourceforge.net Mon May 12 10:43:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 02:43:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-736407 ] Problem With email.MIMEText Package Message-ID: Bugs item #736407, was opened at 2003-05-12 09:41 Message generated for change (Settings changed) made by judasiscariot 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: Open 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470 From noreply@sourceforge.net Mon May 12 12:37:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 04:37:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-736428 ] allow HTMLParser error recovery Message-ID: Bugs item #736428, was opened at 2003-05-12 11:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736428&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Steven Rosenthal (smroid) Assigned to: Nobody/Anonymous (nobody) Summary: allow HTMLParser error recovery Initial Comment: I'm using 2.3a2. HTMLParser correctly raises a "malformed start tag" error on: because my application is imprecise by nature (web scraping), I want to be able to continue after such errors. I can override the error() method to not raise an exception. To make this work, I also needed to alter HTMLParser.py, near line 316, to read as: self.updatepos(i, j) self.error("malformed start tag") return j # ADDED THIS LINE raise AssertionError("we should not get here!") My enhancement request is for every place where self.error() is called, to ensure that the "override error() to not raise an exception" continuation strategy works as well as can be hoped. Thanks, Steve ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736428&group_id=5470 From noreply@sourceforge.net Mon May 12 15:34:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 07:34:37 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-412227 ] explicit regular and arithmetic rshift Message-ID: Feature Requests item #412227, was opened at 2001-03-29 11:41 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=412227&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Dean Hall (dwhall) Assigned to: Nobody/Anonymous (nobody) Summary: explicit regular and arithmetic rshift Initial Comment: Currently, Python uses auto-config tests to determine if its right shift operator ">>" performs regular right shift (RRS) or arithmetic (sign-extended) right shift (ARS). Thus, Python's behavior is dependant on the C compiler. The result for most platforms, is that ">>" is ARS. This leads to some troubling statements in Python syntax: 0xffffffff >> 1 != 0xffffffffL >> 1 -1 >> 5 == -1 The result of defaulting to ARS is that creating a RRS from the ">>" operator consumes more resources than necessary. Whereas, if RRS were the default, it is quite easy to construct the ARS in python syntax: def ARShift(a,b): #bounds checking left out return ~((~a)>>b) I would like to see these things happen: 1. Make explicit operators for ARS and RRS. I've seen ">>" and ">>>" used elsewhere. 2. Make ">>" default to RRS. It will behave more like hardware. Final note: not having RRS available makes programming some algorithms such as Hamming codes and CRC difficult and inefficient. We NEED it! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-12 10:34 Message: Logged In: YES user_id=31435 If it wasn't clear to the OP, Python's >> is always ARS. It's C's that may differ across platforms, and the config tests are to determine whether Python can use the native C >> to get ARS behavior, or whether it has to build ARS on its own. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 04:10 Message: Logged In: YES user_id=357491 In Python 2.4 all hex constants will be positive so you won't have to worry about this any longer. Thus your example of the problem will no longer be an issue once Python 2.4 comes out. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2001-09-14 18:56 Message: Logged In: YES user_id=292741 I see your problem; but this would not generalize to long ints. Those have a conceptually infinite sign extension, so RRS can't ever work on negative long numbers, and is the same as ARS for positive ones. Bearing in mind that even with longs, negative numbers are generated by ~ as well as -. So you gotta '&' with a mask at some point in any case. Even if you had your RRS operation, I suspect you would only get the behaviour you want for 32-bit values. For 16-bit values, you'd have to ^0xFFFF instead of ~, anyway; which is the equivalent slowdown. A >> in C depends not on the compiler but rather the type (signedness) of the LHS; the real difference is that python doesn't have an unsigned int! It is true that all possible workarounds tend to lead to more operators in the inner loop than you want for CRCs and things. I'm thinking of starting a 'ecc' library project for py, which could have a C implementation, and thus go fast. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=412227&group_id=5470 From noreply@sourceforge.net Mon May 12 15:41:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 07:41:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-736467 ] params with default value in __init__ method doesn't work... Message-ID: Bugs item #736467, was opened at 2003-05-12 16: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=736467&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Valery T. (vlry) Assigned to: Nobody/Anonymous (nobody) Summary: params with default value in __init__ method doesn't work... Initial Comment: The handling of constructor parameters with default value have a problem when called many times... It is like the value is cached or something. This is very annoying and easily reproducible :-( Below is the output of what I get on win32 2.2.1 (attached is the code to reproduce) Sincerly, Vlry output: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import bug >>> bug.main() BUG using params with default params... test1= test() 0) __init__ [] 1) self.params= [] 2) self.params= [] 3) self.params= ['default'] test1.getParams() => ['default'] test2= test() 0) __init__ ['default'] 1) self.params= [] 2) self.params= ['default'] 3) self.params= ['default', 'default'] test2.getParams() => ['default', 'default'] test3= test() 0) __init__ ['default', 'default'] 1) self.params= [] 2) self.params= ['default', 'default'] 3) self.params= ['default', 'default', 'default'] test3.getParams() => ['default', 'default', 'default'] OK using initialized params testA= test(['A']) 0) __init__ ['A'] 1) self.params= [] 2) self.params= ['A'] 3) self.params= ['A', 'default'] testA.getParams() => ['A', 'default'] testB= test(['B']) 0) __init__ ['B'] 1) self.params= [] 2) self.params= ['B'] 3) self.params= ['B', 'default'] testB.getParams() => ['B', 'default'] testC= test(['C']) 0) __init__ ['C'] 1) self.params= [] 2) self.params= ['C'] 3) self.params= ['C', 'default'] testC.getParams() => ['C', 'default'] >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736467&group_id=5470 From noreply@sourceforge.net Mon May 12 15:44:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 07:44:17 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-736470 ] An alternative to "range" Message-ID: Feature Requests item #736470, was opened at 2003-05-12 14:44 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=736470&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: An alternative to "range" Initial Comment: As far as I know, range() has often beeing critizised for beeing ugly, particualarly in connection with for-loops. In my eyes, it's also a bit inconsistent that range(x, y) creates a list from x to y, but not including y. My suggestion is to include a pascal-like way of creating lists, with ".." like this: l = [x..y] this would be equal to today's: l = range(x, y + 1) (which I think is quite ugly) Here's another example of how it would look: for i in [1..3]: print i Output: 1 2 3 This could be particularly useful for beginners, and is quite pythonic, as I see it. It's clear and consise, and would be a welcome addition to the python language. In connection with ie. string-manipulation, it would clear up things a great deal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736470&group_id=5470 From noreply@sourceforge.net Mon May 12 15:50:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 07:50:21 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-692881 ] import files from any directory Message-ID: Feature Requests item #692881, was opened at 2003-02-25 13:37 Message generated for change (Comment added) made by alexanro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=692881&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: import files from any directory Initial Comment: Many times I have a .py file with some functions, which I want to import. However, its functionality is very specific, so I don't want to copy it to a directory where it will always be available as a module. If I start Python from the directory of the file, I can import it, but this is not always the case. I can use execfile(), but import is better since it runs the file in its own namespace. What I suggest is to extend the import statement syntax, to allow "module" to be a stringliteral as well as (identifier ".")* identifier. When it is a string literal, the string will be interpreted as the file name to import. The default name of the module will be the name which would import the file if its directory were in PYTHONPATH. If there is no such name, an exception will be raised if "as" is not used. For example, say the file with my functions is called "specific_functions.py" and sits in the directory "/dir". When I open the Python shell from the directory /dir, I can now call "import specific_functions". I suggest that this would do the same thing: "import 'specific_functions.py' ". When I open the Python shell from another directory, I currently have no simple way to import the file, but I suggest that I could use the command "import '/dir/specific_functions.py' ". The command "from '/dir/specific_functions.py' import *" should also work, of course. This has no backward compatibility issues as far as I can see, and is quite helpful, I think. ---------------------------------------------------------------------- Comment By: Alexander Rødseth (alexanro) Date: 2003-05-12 14:50 Message: Logged In: YES user_id=679374 Today, chances are quite good that a random downloaded python-script will function on any computer. This suggestion would increase the chances that one will get errors connected to "missing files" (from 0% to some%, which is a great deal). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=692881&group_id=5470 From noreply@sourceforge.net Mon May 12 16:14:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 08:14:23 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-736490 ] A way to iterate over several variables at once Message-ID: Feature Requests item #736490, was opened at 2003-05-12 15:14 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=736490&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: A way to iterate over several variables at once Initial Comment: Okay. Here's the problem (which occurs frequently in graphics programming): I have, say, variables "red", "green" and "blue". Now I want to iterate "red" from 0 to 63, "green" from 10 to 127 and "blue" from 0 to 255 - all at the same time, and I really, really miss a nice way to do this in Python. Here's my suggestion for how this could be done, (in a better world): for red, green, blue in [0..63], [10..127], [0..255]: print red, green, blue (the ".." is taken from my previous suggestion, so that [0..63] simply means "range(0, 63 + 1)") My idea is that the above code would be translated to something like this (please notice the subtle elegancy of the two lines above, compared with the ones below...): red_list = range(0, 63 + 1) green_list = range(10, 127 + 1) blue_list = range(0, 255 + 1) longest = max(len(red_list), len(green_list), len(blue_list)) red_inc = (red_list[-1] - red_list[0]) / float(longest) green_inc = (green_list[-1] - green_list[0]) / float(longest) blue_inc = (blue_list[-1] - blue_list[0]) / float(longest) red = red_list[0] green = green_list[0] blue = blue_list[0] for count in range(longest): print int(red), int(green), int(blue) red += red_inc green += green_inc blue += blue_inc That's about it. :) (And yes, you could possibly rewrite the "long version" above, in an even cleaner and nicer manner, but still!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&group_id=5470 From noreply@sourceforge.net Mon May 12 16:21:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 08:21:56 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-736490 ] A way to iterate over several variables at once Message-ID: Feature Requests item #736490, was opened at 2003-05-12 15:14 Message generated for change (Comment added) made by alexanro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&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: A way to iterate over several variables at once Initial Comment: Okay. Here's the problem (which occurs frequently in graphics programming): I have, say, variables "red", "green" and "blue". Now I want to iterate "red" from 0 to 63, "green" from 10 to 127 and "blue" from 0 to 255 - all at the same time, and I really, really miss a nice way to do this in Python. Here's my suggestion for how this could be done, (in a better world): for red, green, blue in [0..63], [10..127], [0..255]: print red, green, blue (the ".." is taken from my previous suggestion, so that [0..63] simply means "range(0, 63 + 1)") My idea is that the above code would be translated to something like this (please notice the subtle elegancy of the two lines above, compared with the ones below...): red_list = range(0, 63 + 1) green_list = range(10, 127 + 1) blue_list = range(0, 255 + 1) longest = max(len(red_list), len(green_list), len(blue_list)) red_inc = (red_list[-1] - red_list[0]) / float(longest) green_inc = (green_list[-1] - green_list[0]) / float(longest) blue_inc = (blue_list[-1] - blue_list[0]) / float(longest) red = red_list[0] green = green_list[0] blue = blue_list[0] for count in range(longest): print int(red), int(green), int(blue) red += red_inc green += green_inc blue += blue_inc That's about it. :) (And yes, you could possibly rewrite the "long version" above, in an even cleaner and nicer manner, but still!) ---------------------------------------------------------------------- >Comment By: Alexander Rødseth (alexanro) Date: 2003-05-12 15:21 Message: Logged In: YES user_id=679374 One should possibly also include a way to specify the number of wanted steps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&group_id=5470 From noreply@sourceforge.net Mon May 12 17:33:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 09:33:02 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-736490 ] A way to iterate over several variables at once Message-ID: Feature Requests item #736490, was opened at 2003-05-12 10:14 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Alexander Rødseth (alexanro) >Assigned to: Skip Montanaro (montanaro) Summary: A way to iterate over several variables at once Initial Comment: Okay. Here's the problem (which occurs frequently in graphics programming): I have, say, variables "red", "green" and "blue". Now I want to iterate "red" from 0 to 63, "green" from 10 to 127 and "blue" from 0 to 255 - all at the same time, and I really, really miss a nice way to do this in Python. Here's my suggestion for how this could be done, (in a better world): for red, green, blue in [0..63], [10..127], [0..255]: print red, green, blue (the ".." is taken from my previous suggestion, so that [0..63] simply means "range(0, 63 + 1)") My idea is that the above code would be translated to something like this (please notice the subtle elegancy of the two lines above, compared with the ones below...): red_list = range(0, 63 + 1) green_list = range(10, 127 + 1) blue_list = range(0, 255 + 1) longest = max(len(red_list), len(green_list), len(blue_list)) red_inc = (red_list[-1] - red_list[0]) / float(longest) green_inc = (green_list[-1] - green_list[0]) / float(longest) blue_inc = (blue_list[-1] - blue_list[0]) / float(longest) red = red_list[0] green = green_list[0] blue = blue_list[0] for count in range(longest): print int(red), int(green), int(blue) red += red_inc green += green_inc blue += blue_inc That's about it. :) (And yes, you could possibly rewrite the "long version" above, in an even cleaner and nicer manner, but still!) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-12 11:33 Message: Logged In: YES user_id=44345 This is really very counterintuitive. At one point you say that [0..63] is the same as range(0, 63+1). By extension, [10..127] and [0..255] should also translate to relevant range() calls with step sizes of 1. However, that's not what your code does. You compute the longest sequence and then use that to divide the two shorter sequences into an equal number of steps. It seems you're simply asking for a straight line ramp from (0,10,0) to (63, 127, 255). Image manipulation programs I've used in the past have offered many other ways to proceed from one point in rgb space to another besides simple ramps, so while your desire is pretty common, it's hardly exhausts the reasonable ways to go from point A to point B. Why not write a generator function which takes starting and ending points and a step size, then returns each point in the ramp in turn, something like this only lightly tested code: def ramp(p1, p2, nsteps): "return nsteps points from p1 to p2" stepsize = ((p2[0]-p1[0])/float(nsteps), (p2[1]-p1[1])/float(nsteps), (p2[2]-p1[2])/float(nsteps)) for i in range(nsteps): yield (p1[0]+(stepsize[0]*i), p1[1]+(stepsize[1]*i), p1[2]+(stepsize[2]*i)) (Use range(nsteps+1) if you want to include the endpoint). You would then use it like so: for red, green, blue in ramp((0, 10, 0), (63, 127, 255), 128): print red, green, blue I think this request is too specific for adding to Python. ---------------------------------------------------------------------- Comment By: Alexander Rødseth (alexanro) Date: 2003-05-12 10:21 Message: Logged In: YES user_id=679374 One should possibly also include a way to specify the number of wanted steps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&group_id=5470 From noreply@sourceforge.net Mon May 12 18:03:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:03:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-736467 ] params with default value in __init__ method doesn't work... Message-ID: Bugs item #736467, was opened at 2003-05-12 16:41 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736467&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Valery T. (vlry) Assigned to: Nobody/Anonymous (nobody) Summary: params with default value in __init__ method doesn't work... Initial Comment: The handling of constructor parameters with default value have a problem when called many times... It is like the value is cached or something. This is very annoying and easily reproducible :-( Below is the output of what I get on win32 2.2.1 (attached is the code to reproduce) Sincerly, Vlry output: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import bug >>> bug.main() BUG using params with default params... test1= test() 0) __init__ [] 1) self.params= [] 2) self.params= [] 3) self.params= ['default'] test1.getParams() => ['default'] test2= test() 0) __init__ ['default'] 1) self.params= [] 2) self.params= ['default'] 3) self.params= ['default', 'default'] test2.getParams() => ['default', 'default'] test3= test() 0) __init__ ['default', 'default'] 1) self.params= [] 2) self.params= ['default', 'default'] 3) self.params= ['default', 'default', 'default'] test3.getParams() => ['default', 'default', 'default'] OK using initialized params testA= test(['A']) 0) __init__ ['A'] 1) self.params= [] 2) self.params= ['A'] 3) self.params= ['A', 'default'] testA.getParams() => ['A', 'default'] testB= test(['B']) 0) __init__ ['B'] 1) self.params= [] 2) self.params= ['B'] 3) self.params= ['B', 'default'] testB.getParams() => ['B', 'default'] testC= test(['C']) 0) __init__ ['C'] 1) self.params= [] 2) self.params= ['C'] 3) self.params= ['C', 'default'] testC.getParams() => ['C', 'default'] >>> ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-12 19:03 Message: Logged In: YES user_id=89016 This is not a bug. Default argument values are created once and survive multiple function/method calls. If the default value is mutable and gets changed in one call, the next call will see the changed value. See the FAQ for more info: http://www.python.org/cgi-bin/faqw.py?req=show&file=faq06.025.htp You can either choose another default value and detect that: def __init__(self, ps=None): if ps is None: ps = [] self.params= ps or copy the list on assignment: def __init__(self, ps=[]): self.params= ps[:] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736467&group_id=5470 From noreply@sourceforge.net Mon May 12 18:17:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:17:15 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-736470 ] An alternative to "range" Message-ID: Feature Requests item #736470, was opened at 2003-05-12 09:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736470&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Alexander Rødseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: An alternative to "range" Initial Comment: As far as I know, range() has often beeing critizised for beeing ugly, particualarly in connection with for-loops. In my eyes, it's also a bit inconsistent that range(x, y) creates a list from x to y, but not including y. My suggestion is to include a pascal-like way of creating lists, with ".." like this: l = [x..y] this would be equal to today's: l = range(x, y + 1) (which I think is quite ugly) Here's another example of how it would look: for i in [1..3]: print i Output: 1 2 3 This could be particularly useful for beginners, and is quite pythonic, as I see it. It's clear and consise, and would be a welcome addition to the python language. In connection with ie. string-manipulation, it would clear up things a great deal. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 12:17 Message: Logged In: YES user_id=80475 A language should consistently use either half-open intervals or closed-intervals but *never* mix the two. The same applies to whether lists should be indexed starting at zero or one. Python consistently applies half-open intervals and zero based indexing; any contamination of these unifying themes would be a mistake. The alternatives each have their advantages. With closed intervals, you accurately highlight how easy it is to see the end-point. On the plus side for half-open intervals, it is easier to see how many elements are in the loop (e-b versus e-b+1) and it is easier to link successive intervals because of invariants like a[:n] + a[n:] = a[:]. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736470&group_id=5470 From noreply@sourceforge.net Mon May 12 18:23:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:23:36 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-736490 ] A way to iterate over several variables at once Message-ID: Feature Requests item #736490, was opened at 2003-05-12 10:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Alexander Rødseth (alexanro) Assigned to: Skip Montanaro (montanaro) Summary: A way to iterate over several variables at once Initial Comment: Okay. Here's the problem (which occurs frequently in graphics programming): I have, say, variables "red", "green" and "blue". Now I want to iterate "red" from 0 to 63, "green" from 10 to 127 and "blue" from 0 to 255 - all at the same time, and I really, really miss a nice way to do this in Python. Here's my suggestion for how this could be done, (in a better world): for red, green, blue in [0..63], [10..127], [0..255]: print red, green, blue (the ".." is taken from my previous suggestion, so that [0..63] simply means "range(0, 63 + 1)") My idea is that the above code would be translated to something like this (please notice the subtle elegancy of the two lines above, compared with the ones below...): red_list = range(0, 63 + 1) green_list = range(10, 127 + 1) blue_list = range(0, 255 + 1) longest = max(len(red_list), len(green_list), len(blue_list)) red_inc = (red_list[-1] - red_list[0]) / float(longest) green_inc = (green_list[-1] - green_list[0]) / float(longest) blue_inc = (blue_list[-1] - blue_list[0]) / float(longest) red = red_list[0] green = green_list[0] blue = blue_list[0] for count in range(longest): print int(red), int(green), int(blue) red += red_inc green += green_inc blue += blue_inc That's about it. :) (And yes, you could possibly rewrite the "long version" above, in an even cleaner and nicer manner, but still!) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 12:23 Message: Logged In: YES user_id=80475 FYI, for your applications, Numeric may be very helpful. It has many tools for simulateously manipulation several vectors of the same length It includes functions like Matlab's linspace() and some non- linear variants that address your use case. With linspace() or an equivalent in hand, use zip() to loop over the vectors at the same time (lockstep iteration). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-12 11:33 Message: Logged In: YES user_id=44345 This is really very counterintuitive. At one point you say that [0..63] is the same as range(0, 63+1). By extension, [10..127] and [0..255] should also translate to relevant range() calls with step sizes of 1. However, that's not what your code does. You compute the longest sequence and then use that to divide the two shorter sequences into an equal number of steps. It seems you're simply asking for a straight line ramp from (0,10,0) to (63, 127, 255). Image manipulation programs I've used in the past have offered many other ways to proceed from one point in rgb space to another besides simple ramps, so while your desire is pretty common, it's hardly exhausts the reasonable ways to go from point A to point B. Why not write a generator function which takes starting and ending points and a step size, then returns each point in the ramp in turn, something like this only lightly tested code: def ramp(p1, p2, nsteps): "return nsteps points from p1 to p2" stepsize = ((p2[0]-p1[0])/float(nsteps), (p2[1]-p1[1])/float(nsteps), (p2[2]-p1[2])/float(nsteps)) for i in range(nsteps): yield (p1[0]+(stepsize[0]*i), p1[1]+(stepsize[1]*i), p1[2]+(stepsize[2]*i)) (Use range(nsteps+1) if you want to include the endpoint). You would then use it like so: for red, green, blue in ramp((0, 10, 0), (63, 127, 255), 128): print red, green, blue I think this request is too specific for adding to Python. ---------------------------------------------------------------------- Comment By: Alexander Rødseth (alexanro) Date: 2003-05-12 10:21 Message: Logged In: YES user_id=679374 One should possibly also include a way to specify the number of wanted steps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&group_id=5470 From noreply@sourceforge.net Mon May 12 18:41:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:41:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by gillet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Mon May 12 18:44:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:44:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-729236 ] building readline module fails on Irix 6.5 Message-ID: Bugs item #729236, was opened at 2003-04-28 23:03 Message generated for change (Comment added) made by gillet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: alexandre gillet (gillet) Assigned to: Nobody/Anonymous (nobody) Summary: building readline module fails on Irix 6.5 Initial Comment: I am trying to build Python2.3b1 on a sgi Irix 6.5 using MIPSpro Compilers: Version 7.30 I can't get the readline module to build. I get the following error: cc -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include -I/mgl/prog/share/include/ -c ../Modules/readline.c -o Modules/readline.o cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587 The "return" expression type differs from the function return type. return completion_matches(text, *on_completion); ^ cc-1552 cc: WARNING File = ../Modules/readline.c, Line = 732 The variable "m" is set but never used. PyObject *m; ^ 1 error detected in the compilation of "../Modules/readline.c". gmake: *** [Modules/readline.o] Error 2 ---------------------------------------------------------------------- >Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:44 Message: Logged In: YES user_id=150999 My readline version is 4.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-29 11:44 Message: Logged In: YES user_id=21627 What is your readline version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470 From noreply@sourceforge.net Mon May 12 18:47:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:47:25 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-728304 ] reverse form of enumeration Message-ID: Feature Requests item #728304, was opened at 2003-04-27 01:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=728304&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: reverse form of enumeration Initial Comment: I love the new enumeration builtin. Before it was put in I had my own version of the functionality as many did using xrange and zip. I also used an extension that would give a reverse of what enumeration returns (in behavior at least) enumeration(list) returns an xrange like itterator that behaves like: ( (0, list[0]), (1, list(1)), ...) my old code looked like: def old_enumeration( argList): _ return zip(range(len(argList)), argList) def revenum( argList ): _ temp = old_enumeration( argList) _ temp.reverse() _ return temp obviously this is really slow for really long lists and tuples these structures would be used for looping 90% of the time. One of my fav's: matches = [] for ind, val in revenum(aList): _ if test(val): matches.append(aList.pop(ind)) am I the only person wanting an effecient reverse enumeration?? (NOTE: currently if the list is really long I use: for ind in xrange(len(aList) - 1, -1, -1): create two new lists, then delete the old one. the additional time for pop() is non trivial on a list of 50Mil entries and memory isnt much of a concern as time for me. A reverse enumeration would be much clearer to read IMO). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 12:47 Message: Logged In: YES user_id=80475 You were on target with your question about whether you're the only one wanting C coded reverse enumeration. The use case for going in reverse *and* needing the indices is rare. When needed, it can be cleanly coded in python in just a few lines. You get reasonable performance with your existing code (old_enumeration and revenum). Using a generator and an index variable gives an even cleaner, memory efficient alternative. That latter approach can be brought to near C speed using just two lines from Psyco. On a separate note, the matches example code suffers from O(n^2) run-time because alist.pop(i) has to slide- back every element after i. You do *much* better with: matches=filter(test, alist) and then alist=filter(inversetest, alist). If test() is expensive, then run a single loop that adds each element to either matches or newlist. Also, if you have 50 Mil entries in your lists (which I find surprising with 200Mb for the list of pointers alone and much more memory for the objects being pointed to), then consider using either Numeric or Pysco to get a speed boost. Failing that, the application may warrant a single C function in the time critical section. Unless both the objects and test() are very simple, I would be surprised to find the loop overhead to dominate running time. Also, consider using Py2.3's new itertools module. You ought to get near C speed (as fast as enumerate) from: itertools.izip(xrange(len(aList) - 1, -1, -1), alist) ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-04-27 21:52 Message: Logged In: YES user_id=541557 At issue is the speed of list operations on excessivly large lists. a = list(xrange(5000000)) - 1 second a = list(xrange(50000000)) - 4 min list(enumerate(a))[::-1] is 3 list operations... or 12min (actually took 25min for me in a test but other processes were running. NOTE: the list (xrange(#)) time is NOT included in this.) enumerate(a, reverse=True) - 15seconds (took the code for enumerate and made my own pyd) this does not include the time that it would take to make all the calls to the enumerate's next() method; obviously. in the end, quarter of a min, or quarter of an hour. What would you use? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-27 12:17 Message: Logged In: YES user_id=80475 This runs pretty fast: list(enumerate(data))[::-1] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=728304&group_id=5470 From noreply@sourceforge.net Mon May 12 18:51:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:51:14 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-722498 ] assert could raise other Exceptions Message-ID: Feature Requests item #722498, was opened at 2003-04-16 09:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722498&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: assert could raise other Exceptions Initial Comment: how about having 'assert' check its second parameter, and if it is an instance of Exception, raise that instead of AssertionError: try: n = int(argv[i]) assert 0 <= n < 10, ValueError("n out of range") except ValueError,e: print "Bad parameter:", str(e) This is a fair bit tidier than if not ( 0 <= n < 10 ): raise ValueError, "n out of range" you could also do 'except (ValueError, AssertionError)", but the 'except' might not be so close by, it would be nice to have assert raise something else. Having written this, I just realized that assert is supposed to go away when '-O' is selected (I never use that, myself) so maybe this is not quite as useful -- but still quite free of downside. I know nobody wants a new keyword, how about assert >> ValueError , 0 <= n < 10 , n out of range ... which would do the same as the first example but not be deleted by -O ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 12:51 Message: Logged In: YES user_id=80475 I concur with Martin. While handy, this idea is not consistent with the intended purpose for assertions. Also, I don't find the >> notation to be attractive. I recommend leaving this one out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-18 11:26 Message: Logged In: YES user_id=21627 I don't like this idea. Assertions are something that you can take out without changing the interface (and indeed -O takes them out). They are supposed to never happen, not even when an application uses a library incorrectly. If you need to perform correctness checks on parameters, those checks belong to the API of the function, and should be documented and implemented with a proper if statement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=722498&group_id=5470 From noreply@sourceforge.net Mon May 12 18:52:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:52:50 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-715263 ] Access to DOM Element attributes using __getitem__ Message-ID: Feature Requests item #715263, was opened at 2003-04-04 07:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=715263&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: chris burdess (bluezoo) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Access to DOM Element attributes using __getitem__ Initial Comment: Element objects in XML DOM implementations in Python should provide access to their attributes in a standard Python way, using __getitem__. Thus, the following code to print the version of an XMI document should work: import xml.dom.minidom print xml.dom.minidom.parse(filename).documentElement['xmi.version'] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 12:52 Message: Logged In: YES user_id=80475 At first blush, this seems reasonble. Fred, what do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=715263&group_id=5470 From noreply@sourceforge.net Mon May 12 18:57:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 10:57:18 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-714469 ] Easy tutorial printing should be possible Message-ID: Feature Requests item #714469, was opened at 2003-04-03 04:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Joost Jacob (wspace) Assigned to: Nobody/Anonymous (nobody) Summary: Easy tutorial printing should be possible Initial Comment: I wanted to print the Python Tutorial by Guido for a colleague who might be interested in Python. But this was not easy since it is distributed over a 18 different html files! So now he has something looking bad because page numbers restart at every section. I didn't have the time to think of a better solution: I wanted to give a printed tutorial fast. So the request is this: make the tutorial available in ONE html file so anybody can print it nicely with correct pagenumbers etc. from their browser. This could also be interesting for the other documentation? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 12:57 Message: Logged In: YES user_id=80475 The PDF and PostScript formats are better suited to printing out booklets. Let us know if these links meet your needs: http://www.python.org/doc/current/download.html ---------------------------------------------------------------------- Comment By: Joost Jacob (wspace) Date: 2003-04-03 04:54 Message: Logged In: YES user_id=697662 Jack Jansen mentions availability of PDF files, but I did not find those on the Python web site when I was (in a hurry) looking for the tutorial. Also he mentions "Letter" or "A4" variations, but this is one of the reasons I think one HTML file would be best for each document: the users' browser can print that to postscript or send it directly to a printer with all the users' favorite options. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-03 04:44 Message: Logged In: YES user_id=45365 The tutorial is also available in PDF, but at the moment only if you download an archive containing the full documentation set (on the doc/current/download.html page). Maybe it is a good idea to make the PDFs available separately too? The letter variation is probably best, non-americans are more used to letter than americans to A4, I guess... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470 From noreply@sourceforge.net Mon May 12 19:02:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 11:02:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-729236 ] building readline module fails on Irix 6.5 Message-ID: Bugs item #729236, was opened at 2003-04-28 23:03 Message generated for change (Comment added) made by gillet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: alexandre gillet (gillet) Assigned to: Nobody/Anonymous (nobody) Summary: building readline module fails on Irix 6.5 Initial Comment: I am trying to build Python2.3b1 on a sgi Irix 6.5 using MIPSpro Compilers: Version 7.30 I can't get the readline module to build. I get the following error: cc -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include -I/mgl/prog/share/include/ -c ../Modules/readline.c -o Modules/readline.o cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587 The "return" expression type differs from the function return type. return completion_matches(text, *on_completion); ^ cc-1552 cc: WARNING File = ../Modules/readline.c, Line = 732 The variable "m" is set but never used. PyObject *m; ^ 1 error detected in the compilation of "../Modules/readline.c". gmake: *** [Modules/readline.o] Error 2 ---------------------------------------------------------------------- >Comment By: alexandre gillet (gillet) Date: 2003-05-12 18:02 Message: Logged In: YES user_id=150999 I was able to compile readline on Irix after changing the function flex_complete. the function prototyte say it should return a char** .So we did put the following change and it works. Is it a right way to do it? ** readline.c 2003-05-09 13:45:38.000000000 -0700 --- readline.c~ 2003-03-01 07:19:41.000000000 -0800 *************** *** 577,589 **** /* A more flexible constructor that saves the "begidx" and "endidx" * before calling the normal completer */ ! static char ** flex_complete(char *text, int start, int end) { Py_XDECREF(begidx); Py_XDECREF(endidx); begidx = PyInt_FromLong((long) start); endidx = PyInt_FromLong((long) end); ! return (char **)completion_matches(text, *on_completion); } --- 577,590 ---- /* A more flexible constructor that saves the "begidx" and "endidx" * before calling the normal completer */ ! static char ** ! flex_complete(char *text, int start, int end) { Py_XDECREF(begidx); Py_XDECREF(endidx); begidx = PyInt_FromLong((long) start); endidx = PyInt_FromLong((long) end); ! return completion_matches(text, *on_completion); } ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:44 Message: Logged In: YES user_id=150999 My readline version is 4.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-29 11:44 Message: Logged In: YES user_id=21627 What is your readline version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470 From noreply@sourceforge.net Mon May 12 19:08:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 11:08:10 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-662923 ] iterator for dbm keys Message-ID: Feature Requests item #662923, was opened at 2003-01-05 21:34 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662923&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: iterator for dbm keys Initial Comment: if d is a dbm (gdbm, bsddb, shelve, etc.) object, then "for k in d" should iterate through the keys of d, like you can do with dicts. Alternatively, add a new operation, d.xkeys(), which returns an iterator that steps through all the keys in d. d.keys() is often inappropriate since dbm databases can be extremely large and d.keys() tries to read all the keys into memory at once. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 13:08 Message: Logged In: YES user_id=80475 I think this was taken case of for Python 2.3. Please check to see if all of your needs have been met. If so, please close the request. If not, paste a patch (applying UserDict.DictMixin) for anything that was missed. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2003-02-08 05:27 Message: Logged In: YES user_id=72053 That's nice about shelve, but really, all the dbm classes need this operation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 04:47 Message: Logged In: YES user_id=80475 * for Py2.3, all shelve now inherits from UserDict.DictMixin which adds in the missing methods for a dictionary style interface. * the appropriate name for d.xkeys() is d.iterkeys(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662923&group_id=5470 From noreply@sourceforge.net Mon May 12 19:09:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 11:09:58 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-535324 ] "if foo=bar:" error-message Message-ID: Feature Requests item #535324, was opened at 2002-03-26 13:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=535324&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Guettler (guettli) >Assigned to: Jeremy Hylton (jhylton) Summary: "if foo=bar:" error-message Initial Comment: It would be nice for newbies and tired programmers if the error-message of "if foo=bar" should not only be "SyntaxError: invalid syntax" but "SyntaxError: invalid syntax. Expecting ==" thomas ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 13:09 Message: Logged In: YES user_id=80475 Jeremy, is this easily fixed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-27 07:26 Message: Logged In: YES user_id=21627 Moved into the feature requests tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=535324&group_id=5470 From noreply@sourceforge.net Mon May 12 19:39:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 11:39:44 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-535324 ] "if foo=bar:" error-message Message-ID: Feature Requests item #535324, was opened at 2002-03-26 13:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=535324&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Jeremy Hylton (jhylton) Summary: "if foo=bar:" error-message Initial Comment: It would be nice for newbies and tired programmers if the error-message of "if foo=bar" should not only be "SyntaxError: invalid syntax" but "SyntaxError: invalid syntax. Expecting ==" thomas ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-12 14:39 Message: Logged In: YES user_id=31435 Answering for Jeremy, it isn't. At the point where the construct fails to match any grammar production, *lots* of things are acceptable, from a left parenthesis to "is not". It wouldn't do any good to list all those. '==' is one of the acceptable things then, but that '=' is a prefix of '==' is info that doesn't even survive lexing ('=' comes out as the EQUAL token, '==' as the EQEQUAL token, and there's no more relationship between those than between NAME and STRING tokens). The grammar could be fiddled to allow EQUAL in production comp_op, and then function cmp_type() could be fiddled to say "oops, but the grammar didn't really mean that". That gets very ugly very fast. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 14:09 Message: Logged In: YES user_id=80475 Jeremy, is this easily fixed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-27 07:26 Message: Logged In: YES user_id=21627 Moved into the feature requests tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=535324&group_id=5470 From noreply@sourceforge.net Mon May 12 19:50:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 11:50:09 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-535324 ] "if foo=bar:" error-message Message-ID: Feature Requests item #535324, was opened at 2002-03-26 13:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=535324&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Jeremy Hylton (jhylton) Summary: "if foo=bar:" error-message Initial Comment: It would be nice for newbies and tired programmers if the error-message of "if foo=bar" should not only be "SyntaxError: invalid syntax" but "SyntaxError: invalid syntax. Expecting ==" thomas ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 13:50 Message: Logged In: YES user_id=80475 Thanks Tim. Closing this one as won't fix. It's a nice to have but after a person gets bit once, they quickly learn what the snake looks like. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 13:39 Message: Logged In: YES user_id=31435 Answering for Jeremy, it isn't. At the point where the construct fails to match any grammar production, *lots* of things are acceptable, from a left parenthesis to "is not". It wouldn't do any good to list all those. '==' is one of the acceptable things then, but that '=' is a prefix of '==' is info that doesn't even survive lexing ('=' comes out as the EQUAL token, '==' as the EQEQUAL token, and there's no more relationship between those than between NAME and STRING tokens). The grammar could be fiddled to allow EQUAL in production comp_op, and then function cmp_type() could be fiddled to say "oops, but the grammar didn't really mean that". That gets very ugly very fast. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 13:09 Message: Logged In: YES user_id=80475 Jeremy, is this easily fixed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-27 07:26 Message: Logged In: YES user_id=21627 Moved into the feature requests tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=535324&group_id=5470 From noreply@sourceforge.net Mon May 12 21:34:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 13:34:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-736659 ] markupbase parse_declaration cannot recognize comments Message-ID: Bugs item #736659, was opened at 2003-05-12 16: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=736659&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: markupbase parse_declaration cannot recognize comments Initial Comment: In markupbase class parser method parse_declaration It verfies that the first two characters are " Bugs item #675928, was opened at 2003-01-28 01:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Tim Peters (tim_one) Summary: Have exception arguments keep their type Initial Comment: If you execute the following code:: try: raise Exception('a string') except Exception, err: print type(err) it prints out that ``err`` is a type 'instance'. It would be nice if it returned the type of the actual argument (in this case, type 'str'). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-12 16:55 Message: Logged In: YES user_id=31435 I'm going to put this report of its misery for you . Everything is working as designed here, and won't be changed, so there's no point keeping it open. Note: >>> e = Exception(1, 2, 3) >>> list(e) [1, 2, 3] >>> a, b, c = e >>> a, b, c (1, 2, 3) >>> The detail part of an except clause is an assignment target like any other assignment target, and the only magic here is that Exception decided to make its instances iterable objects, producing the constructor's arguments. Everything else follows from that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 03:35 Message: Logged In: YES user_id=357491 Forgot to mention that I opened patch #726751 to try to clarify. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-25 18:24 Message: Logged In: YES user_id=357491 I played around today and discovered what was confusing me on all of this. Executing the following code:: exc = None try: raise Exception('blah') except Exception, thing: global exc; exc = thing which causes type(exc) == . But if you change the 'except' line to:: except Exception, (thing,): ... then type(exc) == . Obviously when you have a tuple as the target it is unpacking the arguments in the exception (i.e., it is just `` = ``). I just wasn't viewing it as an assignment. I guess the line "exception's parameter is assigned to the target" from the reference manual threw me; I thought it literally meant the parameters to the exception period, not only if there was assignment unpacking. So since this seems to be another case of my quirky common sense not thinking like most people, should this bug report be closed or deleted? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-28 15:57 Message: Logged In: YES user_id=357491 I must be misunderstanding how exceptions handle passed-in values at instantiation. I know you can pass in multiple values (I assume it's ``def __init__(*args, **kwargs)`` for Exception), but I was not expecting an instance type. I think I was expecting the values from ``.args`` to be unpacked and stored in the variables instead of an actual exception object to returned in there with a smart ``__str__`` method. Perhaps the docs should clarify that you receive actual copies of the exception object with its ``args`` attribute set to the argument? The tutorial, as-is, says "the except clause may specify a variable after the exception name (or list) to receive the argument's value" which suggests to me that I will get the physical argument I passed into the exception; I expected tuple unpacking of the ``args`` attribute. In other words I see why it is the way it is, but perhaps we should clarify in the tutorial that it is an exception instance storing the arguments and not the arguments themselves? And I actually used ``str(err)`` to get my code to work, although now that I know that it actually is an instance of an exception it really isn't needed since I will just test for an exception. =) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-28 10:52 Message: Logged In: YES user_id=31435 I'm a bit baffled by this, Brett: when you instantiate a class, you can pass any number of arguments to its constructor. You happened to pass a single string argument when building an instance of Exception here, but you could have passed any number of arguments. Why should the first argument be special? (Or maybe you think the last argument should be special ). Or what if you didn't pass any arguments at all? Having "the detail" bound to the instance object raised is a feature, and a major one. If you're in the habit of passing a single string to Exception directly, note that you can already get it back via doing str(err) in the "except" clause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 From noreply@sourceforge.net Mon May 12 23:55:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 15:55:24 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-414059 ] Floating point second in date/time tuple Message-ID: Feature Requests item #414059, was opened at 2001-04-05 10:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Tim Cera (timcera) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point second in date/time tuple Initial Comment: Would like to have this: >>> time.localtime(1057035600.6) (2003, 7, 1, 1, 0.6, 0, 1, 182, 1) Instead of: >>> time.localtime(1057035600.6) (2003, 7, 1, 1, 0, 0, 1, 182, 1) At a minimum the fractional seconds should be rounded instead of truncated. thanks tim cera ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 15:55 Message: Logged In: YES user_id=357491 The problem is that the C library's localtime is used to do the conversion and that takes in a time_t argument. On almost all platforms this is a long int. Forcing the number to an integer prevent any unexpected warning about casting if the platform does support floats for some odd reason. The reason the argument is truncated is because the argument to PyArg_ParseTuple is 'd', which is integer. Python basically does what C would do which is truncate. You could round it up by taking the number as a Python object, calling Python's round function, and then extract the integer after the rounding. Trouble is that now your value accounts for time that you didn't even have. The plus side to truncating is your are not adding on time that did not occur; you are just losing some extra time you had. =). If you want to create a patch to rectify the situation you might get people to support the idea, but I don't view this as critical, especially when you can call round yourself before passing the value to localtime. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470 From noreply@sourceforge.net Mon May 12 23:58:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 15:58:17 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-414080 ] site-packages initialization Message-ID: Feature Requests item #414080, was opened at 2001-04-05 11:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414080&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ondrej Krajicek (okay) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages initialization Initial Comment: It seems that site.py does not support site-packages on Windows. I do not know whether it is bug or "feature". It does not check neither for site- packages/subdirectories nor pth files. Simple workaround is to reproduce the code which handles site-packages under un*x. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 15:58 Message: Logged In: YES user_id=357491 PEP 250 implemented this and it was added in Python 2.2 Closing as fixed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 13:06 Message: Logged In: YES user_id=6380 It's a "feature" -- it's intentional, although there is some doubt as to whether the Windows policy is right. Anyway, the policy is that the Python root directory, (e.g. C:\Python21) *is* the site-packages directory. Moving this to feature requests because it's reasonable to expect a site-packages directory on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414080&group_id=5470 From noreply@sourceforge.net Tue May 13 00:14:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 16:14:25 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-416670 ] MatchObjects not deepcopy()able Message-ID: Feature Requests item #416670, was opened at 2001-04-17 05:31 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=416670&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 3 Submitted By: Henning Thielemann (amigalemming) Assigned to: Fredrik Lundh (effbot) Summary: MatchObjects not deepcopy()able Initial Comment: In the re-Module which come with Python version 2.0 (Nov 28 11:10 re.py) the created MatchObjects cannot be copied with a deepcopy(). Switching back to the old "pre.py" as proposed in "re.py" makes everything work ok. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 16:14 Message: Logged In: YES user_id=357491 The patch by Martin referenced below was closed since, as Fredrik pointed out in the patch, that re objects have __copy__ and __deepcopy__ methods. Problem is that they are untested so they are basically no-ops after compilation by raising exceptions. So if this feature is still desired someone just needs to work the kinks out of what Fredrik has started. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-28 01:53 Message: Logged In: YES user_id=38376 On the other hand, it looks like we've found a rather elegant way to solve this. I'll leave this one open (as a feature request). ---------------------------------------------------------------------- Comment By: Henning Thielemann (amigalemming) Date: 2001-04-27 03:03 Message: Logged In: YES user_id=197994 You are right, m.groupdict() and m.groups() are surely the better choice. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-26 14:50 Message: Logged In: YES user_id=38376 I'm not sure this is a bug -- imo, you're relying on an implementation artifact in the original PCRE port. And making this work under SRE isn't as easy as it may appear (the proposed patch may work in your specific case, but it isn't a general solution). But before I make up my mind here, maybe you could tell me why you think it's a good idea to use deepcopy on match objects. Why not just store "m.groups()" or "m.regs" instead? Cheers /F ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-26 01:01 Message: Logged In: YES user_id=21627 A patch for that problem is in http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=416670&group_id=5470 From noreply@sourceforge.net Tue May 13 00:34:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 16:34:15 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-419153 ] Issue warning when LC_NUMERIC is not "C" Message-ID: Feature Requests item #419153, was opened at 2001-04-26 08:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=419153&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jürgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: Issue warning when LC_NUMERIC is not "C" Initial Comment: In Py_Initialize(), check that the locale setting for LC_NUMERIC is "C" (and issue some sort of warning if not, e.g. assert() that setting), as required by section 6.22.2 of the Python 2.0 library reference. I'd rather have my embedded interpreter exit() than having VERY strange or even unnoticed problems with floating point constants. The problem I had and that triggered this request was this: Traceback (most recent call last): File "cgi-bin/test.py", line 7, in ? import random File "./random.py", line 93, in ? verify('NV_MAGICCONST', 1.71552776992141) File "./random.py", line 78, in verify raise ValueError, \ ValueError: computed value for NV_MAGICCONST deviates too much (computed 2.82843, expected 1) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 16:34 Message: Logged In: YES user_id=357491 As of Python 2.3b1, the section is now 6.26.2 (locale: For extension writers and programs that embed Python) and it actually says "that the LC_NUMERIC locale should always be "C" ". There is no explicit requirement. Couldn't you do your own check for LC_NUMERIC's value in your own code and raise SystemExit if it isn't set to "C"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=419153&group_id=5470 From noreply@sourceforge.net Tue May 13 00:48:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 16:48:47 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-419903 ] Non-contiguous indexing and slicing Message-ID: Feature Requests item #419903, was opened at 2001-04-28 19:38 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=419903&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Cera (timcera) Assigned to: Nobody/Anonymous (nobody) Summary: Non-contiguous indexing and slicing Initial Comment: I don't know if this has been talked about, I couldn't find it in the PEPs, newsgroup or web site. I use PV-WAVE, a matrix manipulation language similar to MatLab and IDL. PV-WAVE and IDL have the same ancestry. Python, along with arrays from Numeric Python makes a pretty good substitute for PV-WAVE. Plus there are many simularities in syntax between Python and PV-WAVE. PV-WAVE code: PV-WAVE> a=[10,20,30,40,50,60,70,80,90] PV-WAVE> b=[0,4,5,7] PV-WAVE> c=a(b) PV-WAVE> print,c [10, 50, 60, 80] Non-contiguous indexing or is it non-contiguous slicing? Actually it should probably be called dicing. :-) Anyway, I would really like that for Python, so here goes... I find myself doing the following to replicate PV-WAVE's behavoir: >>> a=[10,20,30,40,50,60,70,80,90] >>> b=[0,4,5,7] >>> c=[] >>> for i in b: ... c.append(a[i]) ... >>> c [10, 50, 60, 80] First, just taking the idea from PV-WAVE, for example: >>> c=a[0,4,5,7] >>> c [10,50,60,80] Extending it to include ranges: >>> a[0:3,6:-1] [10,20,30,70,80] Maybe overlapping ranges and mix of indexing and slicing: >>> a[0:4,3:4,0:-1,-1] [10,20,30,40,40,10,20,30,40,50,60,70,80,90] There are some issues: The comma is used in Numerical Python to seperate the array coordinates, so a[0:3,6:-1] is already a legitimate Numerical Python statement. It isn't very pretty. Maybe have a 'dice()' function? >>> a=[10,20,30,40,50,60,70,80,90] >>> b=[0,4,5,7] >>> c=a.dice(b) # or c=dice(a,b) ? >>> c [10,50,60,80] Thanks for Python! ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 16:48 Message: Logged In: YES user_id=357491 I don't see this as worth cluttering up slice notation. I like gaul's suggestion of using a list comprehension to build your list. Heck, you can even simplify the list comp to ``[a[x] for x in b]``. Yes, it is not as short as ``a(b)``, but writing it out it looks like ``[10, 20, 30, 40, 50, 60, 70, 80, 90][[0, 4, 5, 7]]`` which just looks *really* cluttered to me. You also have the built-in 'slice' if you need real control over your slices. So you could do your ``a[0:4, 3:4, 0:-1, -1]`` example as ``[a[slice(*args)] for args in [(0,4), (3,4), (0,-1), (-1,)]]``. God I love list comps. =) ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2001-07-14 15:35 Message: Logged In: YES user_id=139865 Here's a function that gives one some of the functionality you suggested: >>> m=[10,20,30,40,50,60,70,80,90] >>> n=[0,4,5,7] >>> def dice(a, b): ... return [ a[x] for x in xrange(len(a)) if x in b ] ... >>> dice(m, n) [10, 50, 60, 80] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=419903&group_id=5470 From noreply@sourceforge.net Tue May 13 01:08:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 17:08:04 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-443775 ] Update to the BEGIN_ALLOW_THREADS macros Message-ID: Feature Requests item #443775, was opened at 2001-07-23 05:34 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Sjögren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: Update to the BEGIN_ALLOW_THREADS macros Initial Comment: The Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS currently do not support supplying WHERE to save the thread state via an argument. I needed that for a project myself so I wrote the following: #ifdef WITH_THREAD # define MY_BEGIN_ALLOW_THREADS(st) \ { st = PyEval_SaveThread(); } # define MY_END_ALLOW_THREADS(st) \ { PyEval_RestoreThread(st); st = NULL; } #else # define MY_BEGIN_ALLOW_THREADS(st) # define MY_END_ALLOW_THREADS(st) { st = NULL; } #endif This has, of course, the drawback that whenever the Py_BEGIN_ALLOW_THREADS macro changes I have to change mine! Therefore, I propose that these macros (under different names certainly) or macros that work something like this (I can't have asymmetric { and } in them, since I needed to retrieve the thread state somewhere else) in the standard Python distribution. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:08 Message: Logged In: YES user_id=357491 Couldn't you cheat and access the _save variable that Py_BEGIN_ALLOW_THREADS creates? And does PEP 311 help solve your usage need at all? ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-01-17 21:16 Message: Logged In: YES user_id=39274 I think that current Py_BEGIN/END_ALLOW_THREADS macroses model (with block) is choosen to enforce compile-time pairwise check. Isn't it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470 From noreply@sourceforge.net Tue May 13 01:08:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 17:08:55 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-443775 ] Update to the BEGIN_ALLOW_THREADS macros Message-ID: Feature Requests item #443775, was opened at 2001-07-23 05:34 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Martin Sjögren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: Update to the BEGIN_ALLOW_THREADS macros Initial Comment: The Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS currently do not support supplying WHERE to save the thread state via an argument. I needed that for a project myself so I wrote the following: #ifdef WITH_THREAD # define MY_BEGIN_ALLOW_THREADS(st) \ { st = PyEval_SaveThread(); } # define MY_END_ALLOW_THREADS(st) \ { PyEval_RestoreThread(st); st = NULL; } #else # define MY_BEGIN_ALLOW_THREADS(st) # define MY_END_ALLOW_THREADS(st) { st = NULL; } #endif This has, of course, the drawback that whenever the Py_BEGIN_ALLOW_THREADS macro changes I have to change mine! Therefore, I propose that these macros (under different names certainly) or macros that work something like this (I can't have asymmetric { and } in them, since I needed to retrieve the thread state somewhere else) in the standard Python distribution. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:08 Message: Logged In: YES user_id=357491 Couldn't you cheat and access the _save variable that Py_BEGIN_ALLOW_THREADS creates? And does PEP 311 help solve your usage need at all? ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-01-17 21:16 Message: Logged In: YES user_id=39274 I think that current Py_BEGIN/END_ALLOW_THREADS macroses model (with block) is choosen to enforce compile-time pairwise check. Isn't it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470 From noreply@sourceforge.net Tue May 13 01:26:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 17:26:24 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-444582 ] Finding programs in PATH, addition to os Message-ID: Feature Requests item #444582, was opened at 2001-07-25 13:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444582&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: Finding programs in PATH, addition to os Initial Comment: I would like to propose a small addition to the standard Python distribution. I had in mind two additional functions for the os module, but where they fit is subject to debate. They are: 1. which (command[, path]): Finds executable files with the given name in the standard operating system path (os.environ['PATH']) or the user-specified path (which can be a string using the os.pathsep separator, or a Python list of directories in which to search). Availability: UNIX and Windows, at least. I don't know enough about the relevant details of Mac to know whether this is relevant. The attached implementation uses os.access, which is only available on UNIX and Windows. Rationale: It is often useful to check for the existence of a particular program. os.system and os.execp use or mimic the search-in-path functionality, but are often unsuitable for this purpose, because they require running the program right now. Suppose you want to see what's appropriate -- fsh (fast version of ssh), ssh, or rsh (ick) -- and use that decision later on? In the particular case I have in mind, I want to be able to configure my script to say that the sound_player is either esd if there is an executable program with that name in the path, or else none. With which, I can say if which ('esd'): sound_player = 'esd' # or which ('esd') [0] else: sound_player = None Another common use (for me at least) would be for scripts that replace other programs in path, but still need to run the programs they replace. (E.g., I have a script called 'ssh' that resets an xterm's title once the real 'ssh' completes.) This could be done as follows: def find_alternate (program, not_this): for alt in which (program): if not os.path.samefile (alt, not_this): return alt return None / raise ... Counterargument: which is a one-liner (see the attached implementation) Response: In my opinion, it is a longish one-liner, and is only obvious to people who know functional programming (map, reduce, and filter). And in my opinion it is a sufficiently common scripting operation that it warrents a helper function. It is of course a minor feature, but os is filled with many, very helpful, helper routines, and I think this is a similarly useful one. (But this is of course subject to argument.) I made a small inquiry on irc.openprojects.net:#debian about whether this sounded useful, and two people voted yes, and no one voted no. Since the functionality of which is closely matched by os.access, I further propose that which can be specified a different mode than "executable file" by an optional argument. That is included in the attached implementation. 2. find_in_path (command[, path]): Finds all files/directories with the given name in the standard operating system path or the user-specified path (specified as in which). Availability: Everywhere (using os.path.exists instead of os.access) Rationale: This is a natural generalization of which; indeed, which is seen most naturally as a filter of the result of this function. In fact, that is how I implemented which in the attached implementation. More relevantly, this function allows you to find the font with a given name in your font directory, to find the appropriate TeX file in os.environ['TEXINPUTS'], etc., etc. Similar counterpoint/response for this function. Again I think this is a sufficiently common operation to warrent a help function. You are also very welcome to propose a different name than find_in_path. Feel free to post comments for or against this proposal. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:26 Message: Logged In: YES user_id=357491 I don't love the idea of adding either proposed functions. They strike me as rather specific for shell usage and not as something you are necessarily going to want constantly. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2001-07-26 10:21 Message: Logged In: YES user_id=265183 Two things: 1. My apologies for the poor formatting--this was my first sourceforge post. 2. A small correction to the implementation. An instance of '' should be os.defpath (the default value of os.environ['PATH']). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444582&group_id=5470 From noreply@sourceforge.net Tue May 13 01:29:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 17:29:47 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-444805 ] More functions in the C API! Message-ID: Feature Requests item #444805, was opened at 2001-07-26 07:21 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444805&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Martin Sjögren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: More functions in the C API! Initial Comment: I was working with dictionaries in a C module today and I was VERY surprised when I did not find a PyDict_HasKey() function! Apparently the dict_has_key() function is declared static and uses PyArg_ParseTuple() to find out its arguments, and then goes directly down to the object structure. Is this really good? Is there another way to mimic the has_key() behaviour? I ended up calling PyDict_Keys() and looped over it several times instead, not exactly nice. :( ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:29 Message: Logged In: YES user_id=357491 There is ``int PyMapping_HasKeyString(PyObject *o, char *key)`` as specified in the Python/C API in section 6.4 (Mapping Protocol). Does exactly what you want. Closing this RFE as out of date. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-11 09:43 Message: Logged In: YES user_id=21627 Just use PyDict_GetItem. If it returns NULL, the key is not in the dictionary; no need to clear any exceptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444805&group_id=5470 From noreply@sourceforge.net Tue May 13 01:43:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 17:43:02 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-444984 ] Type comparison Message-ID: Feature Requests item #444984, was opened at 2001-07-26 16:38 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444984&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: Type comparison Initial Comment: 1. Let X and Y be classes or types. Currently (X <= Y) == (id(X) <= id(Y)). It would be more useful if (X <= Y) == issubclass(Y, X) Unresolved issue: cmp(X, Y) == ??? 2. Similar proposition for classes and instances: (x in X) == isinstance(x, X) 3. Proposition for Python 3.0: 1 < "1" ==> Exception ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:43 Message: Logged In: YES user_id=357491 But you used issubclass quite well for your need. Is this really worth complicating the comparison code? If you could write a patch to implement this you might be able to get it applied. As for the Python 3 proposition, there has been a discussion of having comparisons like that fail or always return false when the types are different. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2001-09-18 11:40 Message: Logged In: YES user_id=292741 Regarding (1); this is an interesting proposal, the idea is to guarantee that classes sort in such an order that base classes precede the subclasses. A problem here, is that the comparison must have a commutative and transitive property, or it could break all kinds of things; so you need to do something like: XY if Y is a subclass of X , then Y>X otherwise, compare id(X), id(Y) The problem is that if A is a subclass of B, X is a subclass of Y, then A>B, X>Y; but if it turns out that B>X because id(B) > id(X), you would need A>X, A>Y,B>Y to guarantee the transitive property. What I've defined above doesn't do that. Rather a challenge to define a transitive compare with this property. Is it worth it when you already have the issubclass() ? cmp(X,Y) is defined if X Feature Requests item #445484, was opened at 2001-07-28 08:21 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=445484&group_id=5470 Category: None Group: None Status: Open Resolution: Later Priority: 4 Submitted By: Anthony Doggett (anthonydoggett) Assigned to: Nobody/Anonymous (nobody) Summary: pickle lacks float('inf') Initial Comment: Support for float('inf') still appears to be missing in Python 2.1.1 (#1, Jul 28 2001, 14:15:01) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 >>> cPickle.dumps(float('inf'), 1) Traceback (most recent call last): File "", line 1, in ? SystemError: frexp() result out of range >>> pickle.dumps(float('inf'), 1) Traceback (most recent call last): File "", line 1, in ? File "/var/ajd111/python/lib/python2.1/pickle.py", line 943, in dumps Pickler(file, bin).dump(object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 109, in dump self.save(object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 211, in save f(self, object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 273, in save_float self.write(BINFLOAT + pack('>d', object)) SystemError: frexp() result out of range Both structmodule.c and cPickle.c require changes. Surely something like if (x == HUGE_VAL) { /* Inf */ e = 1024; f = 0.0; } else { f = frexp(x, &e); ... and if (e == 1024) x = HUGE_VAL; /* Inf */ else { is all that is required for all IEEE754 machines? (structmodule.c requires similar changes for Float also) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:46 Message: Logged In: YES user_id=357491 PEP 754 should make sure to deal with this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 13:16 Message: Logged In: YES user_id=31435 Changed to Feature Request, and added to new "Non- accidental 754 support" section of PEP 42. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 11:21 Message: Logged In: YES user_id=6380 Is there a point in keeping this bug report open indefinitely? A "won't fix" would make just as much sense. Maybe add Inf support to PEP 42. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 15:41 Message: Logged In: YES user_id=31435 Note that Python has no intentional support for Infs and NaNs anywhere; even that float('inf') doesn't blow up when you do it is a platform accident (it blows up ("invalid literal") on my box). Given that, in the absence of a comprehensive plan for supporting this stuff across the board, and worker bees to implement it, I downgraded the priority. A good plan would refactor the code so that dealing with the platform double and float formats occurs in only one place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=445484&group_id=5470 From noreply@sourceforge.net Tue May 13 01:59:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 17:59:29 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-447143 ] exception item from mapped function Message-ID: Feature Requests item #447143, was opened at 2001-08-02 04:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: exception item from mapped function Initial Comment: The purpose of this enhancement would be to get the item in a list that caused an exception when applying a mapped function. For instance, suppose that I want to detect if there is an item in a list that is not a number. For this illustration I try to map float on the list and then catch the exception. try: map(float, mylist) except ValueError: print "The item %s in mylist is not a number." % (my_item) The problem is that I do not know which item in the list caused the exception. How do I get my_item? This information could probably be useful in a number of different contexts. Thank you. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:59 Message: Logged In: YES user_id=357491 Well, if you were doing this with a list comprehension it isn't hard:: try: float_list = [float(x) for x in mylist] except ValueError: print "The item %s in mylist is not a number." % x Since list comprehensions are practically just a 'for' loop in a much tighter way the variables used stick around just as if you had used a 'for' loop. The other issue is the way errors propogate in C. If map were to return its own error specifying which item caused a problem it would have to overwrite the exception that was raised in the first place and overwriting exceptions on the whole is bad. If you really are in love with map you can always define your own wrapper around float to raise the exception you want:: def myfloat(num): try: return float(num) except ValueError: raise ValueError("The item %s in mylist is not a number." % num) I personally feel this RFE should be rejected. Anyone else agree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 From noreply@sourceforge.net Tue May 13 02:11:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:11:53 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-449187 ] if x in 1,2,3: should work Message-ID: Feature Requests item #449187, was opened at 2001-08-08 09:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 >Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: if x in 1,2,3: should work Initial Comment: There is normally some symmetry between 'for x in whatever' and 'if x in whatever'. However, the symmetry is broken (for syntax reasons I do not understand) in one case, a tuple-without-parentheses: for x in 1, 2, 3: pass works fine, but if x in 1, 2, 3: pass gives a syntax error. Can the syntax error be removed? I think it violates the principle of least astonishment, as one would expect that either both forms would work or neither would. (I'd offer a patch, but I don't think I really understand the way Python syntax is implemented in the Python compiler...!-). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:11 Message: Logged In: YES user_id=357491 I didn't know Python accepted that 'for' structure!?! I agree with Alex that this should be changed at some point. As for why this is, it appears that the offending grammar definitions are: for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] testlist: test (',' test)* [','] test: and_test ('or' and_test)* | lambdef So it looks like the difference is 'for' uses testlist while 'if' uses just test. Probably can just swap out testlist for test and get the result you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 From noreply@sourceforge.net Tue May 13 02:12:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:12:42 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-445484 ] pickle lacks float('inf') Message-ID: Feature Requests item #445484, was opened at 2001-07-28 11:21 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=445484&group_id=5470 Category: None Group: None Status: Open Resolution: Later Priority: 4 Submitted By: Anthony Doggett (anthonydoggett) Assigned to: Nobody/Anonymous (nobody) Summary: pickle lacks float('inf') Initial Comment: Support for float('inf') still appears to be missing in Python 2.1.1 (#1, Jul 28 2001, 14:15:01) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 >>> cPickle.dumps(float('inf'), 1) Traceback (most recent call last): File "", line 1, in ? SystemError: frexp() result out of range >>> pickle.dumps(float('inf'), 1) Traceback (most recent call last): File "", line 1, in ? File "/var/ajd111/python/lib/python2.1/pickle.py", line 943, in dumps Pickler(file, bin).dump(object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 109, in dump self.save(object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 211, in save f(self, object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 273, in save_float self.write(BINFLOAT + pack('>d', object)) SystemError: frexp() result out of range Both structmodule.c and cPickle.c require changes. Surely something like if (x == HUGE_VAL) { /* Inf */ e = 1024; f = 0.0; } else { f = frexp(x, &e); ... and if (e == 1024) x = HUGE_VAL; /* Inf */ else { is all that is required for all IEEE754 machines? (structmodule.c requires similar changes for Float also) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-12 21:12 Message: Logged In: YES user_id=31435 This appears to be outside the scope of PEP 754 (as defined by the PEP's author -- he's just aiming at symbolic constants and inquiry functions). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 20:46 Message: Logged In: YES user_id=357491 PEP 754 should make sure to deal with this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 16:16 Message: Logged In: YES user_id=31435 Changed to Feature Request, and added to new "Non- accidental 754 support" section of PEP 42. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 14:21 Message: Logged In: YES user_id=6380 Is there a point in keeping this bug report open indefinitely? A "won't fix" would make just as much sense. Maybe add Inf support to PEP 42. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-01 18:41 Message: Logged In: YES user_id=31435 Note that Python has no intentional support for Infs and NaNs anywhere; even that float('inf') doesn't blow up when you do it is a platform accident (it blows up ("invalid literal") on my box). Given that, in the absence of a comprehensive plan for supporting this stuff across the board, and worker bees to implement it, I downgraded the priority. A good plan would refactor the code so that dealing with the platform double and float formats occurs in only one place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=445484&group_id=5470 From noreply@sourceforge.net Tue May 13 02:38:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:38:02 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-449187 ] if x in 1,2,3: should work Message-ID: Feature Requests item #449187, was opened at 2001-08-08 12:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: if x in 1,2,3: should work Initial Comment: There is normally some symmetry between 'for x in whatever' and 'if x in whatever'. However, the symmetry is broken (for syntax reasons I do not understand) in one case, a tuple-without-parentheses: for x in 1, 2, 3: pass works fine, but if x in 1, 2, 3: pass gives a syntax error. Can the syntax error be removed? I think it violates the principle of least astonishment, as one would expect that either both forms would work or neither would. (I'd offer a patch, but I don't think I really understand the way Python syntax is implemented in the Python compiler...!-). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-12 21:38 Message: Logged In: YES user_id=31435 The fundamental problem is that, as an expression, "x in 1, 2, 3" doesn't group as an if-statement would need it to group: >>> y = 'a' in 'a', 'b', 'c' >>> y (True, 'b', 'c') >>> >>> for y in 'a' in 'a', 'b', 'c': ... print y ... True b c >>> So if Python did allow a testlist as the 'if' expression, it would be parsed as: if ((x in 1), 2, 3): which is a surprising way of raising TypeError. The parens are really needed to get the 1, 2, 3 part parsed as a tuple. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:11 Message: Logged In: YES user_id=357491 I didn't know Python accepted that 'for' structure!?! I agree with Alex that this should be changed at some point. As for why this is, it appears that the offending grammar definitions are: for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] testlist: test (',' test)* [','] test: and_test ('or' and_test)* | lambdef So it looks like the difference is 'for' uses testlist while 'if' uses just test. Probably can just swap out testlist for test and get the result you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 From noreply@sourceforge.net Tue May 13 02:46:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:46:42 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-453506 ] lists should have a copy method Message-ID: Feature Requests item #453506, was opened at 2001-08-20 14:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lists should have a copy method Initial Comment: This is per someone on comp.os.python. It's odd that dictionaries have a copy method (you can say dict.copy()) but to copy a list you have to say list[:] or use copy.copy. I think list.copy() should be added for consistency. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:46 Message: Logged In: YES user_id=357491 I'm with Tim; you don't need seven ways to copy (Tim forgot using a list comprehension and ``map(None, list)`` =). I say this RFE gets rejected. ---------------------------------------------------------------------- Comment By: Jesper Hertel (jhmagnus) Date: 2003-01-21 06:30 Message: Logged In: YES user_id=592328 I agree that it would be nice (and consistent) if lists had a copy() method. It would be more convenient. It is always tiresome to have to import modules to do simple stuff like this. The list[:] is a trick that you have to know before you can use it (it doesn't seem obvious to me), but list.copy() seems intuitive to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 22:43 Message: Logged In: YES user_id=31435 I doubt Guido would go for it. dicts grew a .copy() method *because* there was no convenient syntax like list[:] that worked for dicts. That's not a reason to add a .copy() method to lists too. Note that if you're too fond of uniformity , don't use any of these: use copy.copy() or copy.deepcopy(). Python doesn't need four ways to spell "copy this list". Oops: make that five. list (somelist) also copies a list. In 2.2, dict(somedict) also copies a dict. Enough already. ---------------------------------------------------------------------- Comment By: Michael Gilfix (mgilfix) Date: 2002-04-22 20:53 Message: Logged In: YES user_id=116038 What's the status of this? It seems pretty useful. I could submit a patch if someone likes... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 From noreply@sourceforge.net Tue May 13 02:49:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:49:37 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-453677 ] statements should return a value Message-ID: Feature Requests item #453677, was opened at 2001-08-21 04:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453677&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: statements should return a value Initial Comment: In the Ruby language all constructs have a value. For example an if-construct returns a value, so you can use if also on the right side of an expression. I think that it would be really great to have the same in Python. That would permit to: #1 emulate the C ternary operator ?: y= 10 * if x>0 : 1 else : -1 I find it more intuitive than the a and b or c construct and drop out the b==0 bug The only potential problem is operator priority: should y = if x%2: x+1 else: x/2 mean : (a) y = if x%2: (x+1) else: (x/2) or (b) y = (if x%2: x+1 else: x)/2 I think (a) is the right answer #2 replace lambda statement f= def x,y : x+y This new syntax of def statement could permit to create anonymous functions. Because the classical def f(x): statement will now returning a value, this would be really intuitive and permit to reduce the number of concepts in the language (instead of def and lambda statements, we will have only def statements with optional function name specification) #3 make list completion more linked with the language List completion is really useful but it's syntax is not very consistent with the language. Now we could have: Squares = for i in range(10): i**2 Sequence = for i in range(10): if i%2 : 3*i+1 else: i/2 One potential problem is filtering: We want that: (for i in range(5): if i%2 : i) == (1,3) (for i in range(5): if i%2 : i else : None) == (None,1,None,3,None) i=4; (if i%2 : i) == None One solution would be to create a new value NO_RET_VAL wich is returned by the if statement when no else have been executed. This value is automatically converted to None except when it is caught by a for or a while statement. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:49 Message: Logged In: YES user_id=357491 No way. We do not need people to suddenly start doing assignment in 'if' statements like C. I know for a fact there is no way that this is going to happen, *ever*. I am going to close and reject this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453677&group_id=5470 From noreply@sourceforge.net Tue May 13 02:53:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:53:31 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-449187 ] if x in 1,2,3: should work Message-ID: Feature Requests item #449187, was opened at 2001-08-08 09:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: if x in 1,2,3: should work Initial Comment: There is normally some symmetry between 'for x in whatever' and 'if x in whatever'. However, the symmetry is broken (for syntax reasons I do not understand) in one case, a tuple-without-parentheses: for x in 1, 2, 3: pass works fine, but if x in 1, 2, 3: pass gives a syntax error. Can the syntax error be removed? I think it violates the principle of least astonishment, as one would expect that either both forms would work or neither would. (I'd offer a patch, but I don't think I really understand the way Python syntax is implemented in the Python compiler...!-). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:53 Message: Logged In: YES user_id=357491 That's why I want for to be changed so that it needs parentheses. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 18:38 Message: Logged In: YES user_id=31435 The fundamental problem is that, as an expression, "x in 1, 2, 3" doesn't group as an if-statement would need it to group: >>> y = 'a' in 'a', 'b', 'c' >>> y (True, 'b', 'c') >>> >>> for y in 'a' in 'a', 'b', 'c': ... print y ... True b c >>> So if Python did allow a testlist as the 'if' expression, it would be parsed as: if ((x in 1), 2, 3): which is a surprising way of raising TypeError. The parens are really needed to get the 1, 2, 3 part parsed as a tuple. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:11 Message: Logged In: YES user_id=357491 I didn't know Python accepted that 'for' structure!?! I agree with Alex that this should be changed at some point. As for why this is, it appears that the offending grammar definitions are: for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] testlist: test (',' test)* [','] test: and_test ('or' and_test)* | lambdef So it looks like the difference is 'for' uses testlist while 'if' uses just test. Probably can just swap out testlist for test and get the result you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 From noreply@sourceforge.net Tue May 13 02:57:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:57:33 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-453506 ] lists should have a copy method Message-ID: Feature Requests item #453506, was opened at 2001-08-20 17:23 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 1 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: lists should have a copy method Initial Comment: This is per someone on comp.os.python. It's odd that dictionaries have a copy method (you can say dict.copy()) but to copy a list you have to say list[:] or use copy.copy. I think list.copy() should be added for consistency. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-12 21:57 Message: Logged In: YES user_id=31435 Assigned to Guido for rejection . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:46 Message: Logged In: YES user_id=357491 I'm with Tim; you don't need seven ways to copy (Tim forgot using a list comprehension and ``map(None, list)`` =). I say this RFE gets rejected. ---------------------------------------------------------------------- Comment By: Jesper Hertel (jhmagnus) Date: 2003-01-21 09:30 Message: Logged In: YES user_id=592328 I agree that it would be nice (and consistent) if lists had a copy() method. It would be more convenient. It is always tiresome to have to import modules to do simple stuff like this. The list[:] is a trick that you have to know before you can use it (it doesn't seem obvious to me), but list.copy() seems intuitive to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-23 01:43 Message: Logged In: YES user_id=31435 I doubt Guido would go for it. dicts grew a .copy() method *because* there was no convenient syntax like list[:] that worked for dicts. That's not a reason to add a .copy() method to lists too. Note that if you're too fond of uniformity , don't use any of these: use copy.copy() or copy.deepcopy(). Python doesn't need four ways to spell "copy this list". Oops: make that five. list (somelist) also copies a list. In 2.2, dict(somedict) also copies a dict. Enough already. ---------------------------------------------------------------------- Comment By: Michael Gilfix (mgilfix) Date: 2002-04-22 23:53 Message: Logged In: YES user_id=116038 What's the status of this? It seems pretty useful. I could submit a patch if someone likes... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 From noreply@sourceforge.net Tue May 13 02:59:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 18:59:51 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-456086 ] virtual IO for embedding Py in server Message-ID: Feature Requests item #456086, was opened at 2001-08-28 04:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=456086&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: virtual IO for embedding Py in server Initial Comment: Embedding Py inside an Admin server program could be extremly useful. This is how I wish to embedd Py: 1. The server program runs on Windows NT. thus fork () is not applicable. 2. The server is Multi-User, thus Py needs to be thread-safe - global variables need to be eliminated or locked. 3. The server needs to process the input & output of Py. furthermore, the server communicates with clients in several methods, not all can be represented with a FILE* object. My request is that a) Py will be made thread-safe, so several scripts could be run simultaneously in the same process, by different users. b) Py will 'virtualize' IO in an object-oriented like manner. This is difficult, since Py is implemented in C, but not impossible. consider this struct as a possible replacement for FILE* & fprintf: // typedef for 'this' typedef void* VContext; // typedef for function pointers typedef void (p_vflush*)(VContext) // func. pointer typedef void (p_vprintf*)(VContext, const char *format, ....); struct VOutput { p_vflush vflush; p_vprintf fprintf; VContext vcontext; }; it is fairly easy to implement FILE* style IO using this style, and it allows a much more flexible ways of doing IO. The two major issues hold back embedding ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:59 Message: Logged In: YES user_id=357491 Making the core thread-safe is a tremendous undertaking. I doubt it will happen any time soon if ever. As for your virtualized IO, Guido is working on a stream-based IO package to allow standardized control over IO. You might want to have a look. It is in the nondist/ directory of the CVS and its called sio . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=456086&group_id=5470 From noreply@sourceforge.net Tue May 13 03:03:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:03:25 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-468153 ] os.fork() in win32 port Message-ID: Feature Requests item #468153, was opened at 2001-10-04 20:15 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468153&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: os.fork() in win32 port Initial Comment: The only thing that would make the windows version of python fully functional (in my opinion), is os.fork(). I don't know where the real issue lies in this, whether it's a win32 api problem or not. I would use the cygwin port of python, which has support for os.fork(), except that it has broken thread support (an issue with cygwin's posix threads). As a side note, cygwin's python has much faster console IO...roughly on the order of 10x or more. Strange feature... ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:03 Message: Logged In: YES user_id=357491 I have heard it stated enough times that os.fork is not available on Windows since it just does not provide it that I think this should be closed. Any objections? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2001-10-16 07:04 Message: Logged In: YES user_id=341410 I actually hadn't noticed the spawn* operations in the OS module. I can see how passing arguments to a command line could be a bit cumbersome, especially when the fork or spawn was supposed to be in deep control flow. I'm sure that I could get it to work for most anything I would need it to do, but like how fork is implemented in cygwin, os.spawn* seems to be quite hacky, or at least one's code using it and recovering from it could be. Part of the reason I didn't know about the spawn functions is that while having used fork in c (in *nix and cygwin), neither c/c++ courses nor operating systems courses teach about spawn (I don't know much about c/c++, and do not know if it is a python specific operator or if it is available in other languages), but they do teach about fork. As a user of the language, if I need a feature that I've used in another language, I look for something with a similar name to what I've already used. To get people to learn about spwan, referring to it in the fork section of the documentation as an alternative to fork on win32 and *nix would possibly make it wider known. Thank you for the information, - Josiah ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-16 01:04 Message: Logged In: YES user_id=21627 I believe fork is unimplementable correctly with the Win32 API. There is simply no API call for "create a process that shares address space with the original process in a copy-on-write fashion". Instead, cygwin creates a new process, and then copies the complete address space from one process to the other. This looks quite hacky, and I think Python users should accept that fork is system specific, and use os.spawn* instead. Can you please explain why you need fork, and why spawnv is not sufficient? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468153&group_id=5470 From noreply@sourceforge.net Tue May 13 03:08:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:08:40 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-478407 ] Need Windows os.link() support Message-ID: Feature Requests item #478407, was opened at 2001-11-05 11:34 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=478407&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Need Windows os.link() support Initial Comment: NTFS has (always?) had hard link support. This functionality is now exposed in Win32 starting with Windows 2000 [see CreateHardLink()]. I've added Windows support to os.link(). I've tried to support FAT, NT, 95 by doing a CopyFile(). 2000 support is enabled by defining _WIN32_WINNT=0x500 in pythoncore.dsp. When this is done, the redundant #include in errnomodule.c gives compilation errors. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:08 Message: Logged In: YES user_id=357491 If you would like this to actually be looked at it would be best to create a patch against CVS and upload a diff file instead of a zip file. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-01-17 21:49 Message: Logged In: YES user_id=39274 Also one can create os.symlink() and os.readlink() for all windows versions after 95 - using shell links (like cygwin do for symlink emulation). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-05 11:35 Message: Logged In: NO I think that I forgot to add my email address: bcox@semio.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=478407&group_id=5470 From noreply@sourceforge.net Tue May 13 03:22:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:22:57 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-574465 ] Docs in DocBook format Message-ID: Feature Requests item #574465, was opened at 2002-06-26 23:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=574465&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: Docs in DocBook format Initial Comment: The current documentation in LaTeX makes it hard to convert it to anything other than the supported formats (PS,PDF,HTML). To generate all documentation (including .info docs) you'd have to install TeX (plus some conversion tools), Perl and Emacs. How about making the docs in DocBook format? Its a lot of work, but it would help format conversion a lot without installing additional software. Greetings, Bastian ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:22 Message: Logged In: YES user_id=357491 But wouldn't DocBook then require having Java installed? Chances are if you wanted to do the conversion you would write a program to do it for you. But at that point you negate the need to have it in DocBook natively since you have the conversion tool. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=574465&group_id=5470 From noreply@sourceforge.net Tue May 13 03:25:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:25:02 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-563141 ] fileinput/gzip modules should play well Message-ID: Feature Requests item #563141, was opened at 2002-05-31 17:27 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg White (groggygreggy) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput/gzip modules should play well Initial Comment: It seems to be nearly impossible to use the fileinput module to read gzip files, even though gzip support is available in the gzip module. As a first step, it would be nice if the fileinput.FileInput class provided an overridable method that let outsiders glue the gzip module in place. It would also be nice if there was a way to make fileinput just automatically support gzip files (if, for instance, it saw a .gz extension). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:25 Message: Logged In: YES user_id=357491 The hook is reasonable, the automatic opening of gzip is not. No need to have magic done based purely on extension. Any chance you could write a patch to expose the hook? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470 From noreply@sourceforge.net Tue May 13 03:32:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:32:04 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-585915 ] assert return values Message-ID: Feature Requests item #585915, was opened at 2002-07-24 06:28 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=585915&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Leonard (tal197) Assigned to: Nobody/Anonymous (nobody) Summary: assert return values Initial Comment: It would be nice to write: def root(x): assert x >= 0 assert return >= 0 ... or def get_path(foo): if foo is None: return None assert return is not None ... and have the 'return' assertion checked when the function exits. 'return' is already a reserved keyword so the syntax doesn't introduce any incompatibility. This might make functions more self-documenting, since asserts at the end / in the middle tend to get lost. Even if the assert goes at the end, it's still clearer, eg: def foo(): ... assert min <= return <= max return bar(min, max) vs def foo(): ... tmp = bar(min, max) assert min <= tmp <= max return tmp Thanks! ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:32 Message: Logged In: YES user_id=357491 Wouldn't this require turning 'return' into an expression instead of a statement? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-24 08:42 Message: Logged In: YES user_id=31435 Re-opened but moved to the Feature Request tracker (it's certainly not "a bug", but there's no rule against asking for new features either, provided they're in the right place). I don't believe there's any control flow in the suggestion, just that the name "return" be taken as being bound, in assert statements, to the possibly anonyous return expression. Eiffel does something very much like this for the benefit of expressing post-conditions. I certainly agree this way of spelling it in Python has problems, though, and a PEP would be in order. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-24 08:06 Message: Logged In: YES user_id=31392 I don't think this is a great feature. It seems like control flow via yield or return could easily be overlooked if it's inside an assert statement. Regardless of whether I like the idea, the SF bug tracker isn't the right place to make this suggestion. The right thing to do is write a PEP describing the feature in detail, then come up with a patch to implement it. If that's too much work, but you really like the idea, you could try to drum up interest on comp.lang.python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=585915&group_id=5470 From noreply@sourceforge.net Tue May 13 03:35:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:35:21 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-468153 ] os.fork() in win32 port Message-ID: Feature Requests item #468153, was opened at 2001-10-04 23:15 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468153&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: os.fork() in win32 port Initial Comment: The only thing that would make the windows version of python fully functional (in my opinion), is os.fork(). I don't know where the real issue lies in this, whether it's a win32 api problem or not. I would use the cygwin port of python, which has support for os.fork(), except that it has broken thread support (an issue with cygwin's posix threads). As a side note, cygwin's python has much faster console IO...roughly on the order of 10x or more. Strange feature... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-12 22:35 Message: Logged In: YES user_id=31435 Yes, feel free to close it. Implementing fork() on Windows requires heroic effort, and the result isn't pretty. BTW, note that fork() isn't defined by the C standard -- it's very much an OS gimmick. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 22:03 Message: Logged In: YES user_id=357491 I have heard it stated enough times that os.fork is not available on Windows since it just does not provide it that I think this should be closed. Any objections? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2001-10-16 10:04 Message: Logged In: YES user_id=341410 I actually hadn't noticed the spawn* operations in the OS module. I can see how passing arguments to a command line could be a bit cumbersome, especially when the fork or spawn was supposed to be in deep control flow. I'm sure that I could get it to work for most anything I would need it to do, but like how fork is implemented in cygwin, os.spawn* seems to be quite hacky, or at least one's code using it and recovering from it could be. Part of the reason I didn't know about the spawn functions is that while having used fork in c (in *nix and cygwin), neither c/c++ courses nor operating systems courses teach about spawn (I don't know much about c/c++, and do not know if it is a python specific operator or if it is available in other languages), but they do teach about fork. As a user of the language, if I need a feature that I've used in another language, I look for something with a similar name to what I've already used. To get people to learn about spwan, referring to it in the fork section of the documentation as an alternative to fork on win32 and *nix would possibly make it wider known. Thank you for the information, - Josiah ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-16 04:04 Message: Logged In: YES user_id=21627 I believe fork is unimplementable correctly with the Win32 API. There is simply no API call for "create a process that shares address space with the original process in a copy-on-write fashion". Instead, cygwin creates a new process, and then copies the complete address space from one process to the other. This looks quite hacky, and I think Python users should accept that fork is system specific, and use os.spawn* instead. Can you please explain why you need fork, and why spawnv is not sufficient? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468153&group_id=5470 From noreply@sourceforge.net Tue May 13 03:50:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:50:59 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-616441 ] urllib.urlencode Message-ID: Feature Requests item #616441, was opened at 2002-09-30 02:28 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=616441&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Allan Crooks (amc1) >Assigned to: Brett Cannon (bcannon) Summary: urllib.urlencode Initial Comment: The documentation should mention that for urllib.urlencode, it has an inverse function which is cgi.parse_qs (and vice versa). I was initially looking for a urllib.urldecode function, and then thought there wasn't a function to do what I needed. Alternatively, these functions may need to be grouped together. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:50 Message: Logged In: YES user_id=357491 Done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=616441&group_id=5470 From noreply@sourceforge.net Tue May 13 03:54:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:54:07 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-468153 ] os.fork() in win32 port Message-ID: Feature Requests item #468153, was opened at 2001-10-04 20:15 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468153&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: os.fork() in win32 port Initial Comment: The only thing that would make the windows version of python fully functional (in my opinion), is os.fork(). I don't know where the real issue lies in this, whether it's a win32 api problem or not. I would use the cygwin port of python, which has support for os.fork(), except that it has broken thread support (an issue with cygwin's posix threads). As a side note, cygwin's python has much faster console IO...roughly on the order of 10x or more. Strange feature... ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2003-05-12 19:52 Message: Logged In: YES user_id=341410 Yeah, close the bad boy...it's been a while since I cared about fork support...I'll attempt to do so. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 19:35 Message: Logged In: YES user_id=31435 Yes, feel free to close it. Implementing fork() on Windows requires heroic effort, and the result isn't pretty. BTW, note that fork() isn't defined by the C standard -- it's very much an OS gimmick. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:03 Message: Logged In: YES user_id=357491 I have heard it stated enough times that os.fork is not available on Windows since it just does not provide it that I think this should be closed. Any objections? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2001-10-16 07:04 Message: Logged In: YES user_id=341410 I actually hadn't noticed the spawn* operations in the OS module. I can see how passing arguments to a command line could be a bit cumbersome, especially when the fork or spawn was supposed to be in deep control flow. I'm sure that I could get it to work for most anything I would need it to do, but like how fork is implemented in cygwin, os.spawn* seems to be quite hacky, or at least one's code using it and recovering from it could be. Part of the reason I didn't know about the spawn functions is that while having used fork in c (in *nix and cygwin), neither c/c++ courses nor operating systems courses teach about spawn (I don't know much about c/c++, and do not know if it is a python specific operator or if it is available in other languages), but they do teach about fork. As a user of the language, if I need a feature that I've used in another language, I look for something with a similar name to what I've already used. To get people to learn about spwan, referring to it in the fork section of the documentation as an alternative to fork on win32 and *nix would possibly make it wider known. Thank you for the information, - Josiah ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-16 01:04 Message: Logged In: YES user_id=21627 I believe fork is unimplementable correctly with the Win32 API. There is simply no API call for "create a process that shares address space with the original process in a copy-on-write fashion". Instead, cygwin creates a new process, and then copies the complete address space from one process to the other. This looks quite hacky, and I think Python users should accept that fork is system specific, and use os.spawn* instead. Can you please explain why you need fork, and why spawnv is not sufficient? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=468153&group_id=5470 From noreply@sourceforge.net Tue May 13 03:56:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:56:09 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-622230 ] def object.new_method(self): Message-ID: Feature Requests item #622230, was opened at 2002-10-11 23:04 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Nobody/Anonymous (nobody) Summary: def object.new_method(self): Initial Comment: I want to be able to create functions inside objects instead of having to do: class x: pass def new_method(self): pass x.new_method = new_method del new_method I want to do: class x: pass def x.new_method(self): pass Why isn't this possible? Wouldn't it be cool? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:56 Message: Logged In: YES user_id=357491 I am with Raymond and Martin on this; I don't see this being worth the hassle of implementing. Should we reject this or leave it open for contemplative thought? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-03 01:16 Message: Logged In: YES user_id=80475 This is an interesting idea but (from your example) the only way to use it is when the names are already known statically when writing the code. And, if you already know x and newmethod, why not write: class x: def new_method(self): pass The only use case I can see is if the source for x is unaccessible in another module: from M import x def x.newmethod(self): pass All in all, this would be a tough sell (and likely require a PEP) because the effort to implement it, document it, explain it and support it isn't warrented by the two line savings over what can already be done. Further, the current one-way-to-do-it is robust, clear, and can work dynamically as well as at coding time. I'm -1 on this one but do think it reflects original creative thought. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 02:29 Message: Logged In: YES user_id=21627 It's simply not possible because nobody has though of that. I personally would not consider it cool: Python expresses nesting of definition with indentation, not with full-stop separators. Unless you implement it yourself, I'd expect that it is unlilkely that anybody will act on this request in the coming years. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2002-10-11 23:08 Message: Logged In: YES user_id=118203 Repost with attempted better formatting: I don't want to do: class x:     pass def new_method(self):     pass x.new_method = new_method del new_method I want to do: class x:     pass def x.new_method(self):     pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 From noreply@sourceforge.net Tue May 13 03:58:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 19:58:36 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class Message-ID: Feature Requests item #635144, was opened at 2002-11-07 11:49 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Raymond Hettinger (rhettinger) Summary: New UniDiffer class Initial Comment: Attached is a new UniDiffer module, based on the difflib.Differ class, which outputs GNU diff unified context format compatible lines. The class includes doctest tests and is intended to be merged directly into the difflib module. Jim Fulton saiz this can be added to the Python Library under the current Python license. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:58 Message: Logged In: YES user_id=357491 Should this be made a patch instead of an RFE? ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 11:14 Message: Logged In: YES user_id=116747 'Nother version. One bug fix, one new feature. - When two hunks were between 2 * context + 1 and 3* context lines aparart, the starting context for the second hunk would be partially lost. - Handle missing newline on the last line like GNU diff does. This currently only supports UNIX-style lineendings. Documentation reflects this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 08:18 Message: Logged In: YES user_id=116747 And another little bug found: if set a is empty and set b is not, resulting in all added lines, an empty diff would be returned. Attached latest version fixes this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 13:34 Message: Logged In: YES user_id=116747 Another update: when there were more than [context] lines in between two updates, but less than 2 * [context], the two chunks should not be split. This version fixes that problem; we look ahead an extra [context] lines before cutting the chunk. Also, timestamps in headers are now show the seconds fraction as well, just like GNU diff. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 12:00 Message: Logged In: YES user_id=116747 New version attached, fixing a context bug. There was a small bug in the previous version where, if context was set to 0, the all lines until the end of the last chunk were shown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 From noreply@sourceforge.net Tue May 13 04:25:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 20:25:22 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-600362 ] relocate cgi.parse_qs() into urlparse Message-ID: Feature Requests item #600362, was opened at 2002-08-26 11:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=600362&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: relocate cgi.parse_qs() into urlparse Initial Comment: The location of the url-handling functions are distributed among several modules, and it would be good to consolidate them to make them easier to find. The urlparse.urlparse() function splits an url into its relative pieces. However, it does not parse out the query string into a dictionary --- that role is played by cgi.parse_qs(). And to convert a dictionary back to a query string, the programmer needs to know that that function is in urllib.urlencode. It would be nice to have cgi.parse_qs() and urllib.urlencode() in a unified place, within in the urlparse module if appropriate. This will help reduce the amount of hunting-and-pecking that beginners do when they're trying to deal with URLs. See: http://mail.python.org/pipermail/tutor/2002-August/016823.html for more information. Thanks! ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 20:25 Message: Logged In: YES user_id=357491 This is a problem. Should a wrapper in urlparse for cgi.parse_qs but created or should it just be documented that to parse a query string you should use cgi.parse_qs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=600362&group_id=5470 From noreply@sourceforge.net Tue May 13 04:49:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 20:49:46 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class Message-ID: Feature Requests item #635144, was opened at 2002-11-07 14:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Raymond Hettinger (rhettinger) Summary: New UniDiffer class Initial Comment: Attached is a new UniDiffer module, based on the difflib.Differ class, which outputs GNU diff unified context format compatible lines. The class includes doctest tests and is intended to be merged directly into the difflib module. Jim Fulton saiz this can be added to the Python Library under the current Python license. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 22:49 Message: Logged In: YES user_id=80475 Nope. I have to blend this patch with another implementation and combine the best parts of each. The SF is fine as it stands. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:58 Message: Logged In: YES user_id=357491 Should this be made a patch instead of an RFE? ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 14:14 Message: Logged In: YES user_id=116747 'Nother version. One bug fix, one new feature. - When two hunks were between 2 * context + 1 and 3* context lines aparart, the starting context for the second hunk would be partially lost. - Handle missing newline on the last line like GNU diff does. This currently only supports UNIX-style lineendings. Documentation reflects this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 11:18 Message: Logged In: YES user_id=116747 And another little bug found: if set a is empty and set b is not, resulting in all added lines, an empty diff would be returned. Attached latest version fixes this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 16:34 Message: Logged In: YES user_id=116747 Another update: when there were more than [context] lines in between two updates, but less than 2 * [context], the two chunks should not be split. This version fixes that problem; we look ahead an extra [context] lines before cutting the chunk. Also, timestamps in headers are now show the seconds fraction as well, just like GNU diff. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 15:00 Message: Logged In: YES user_id=116747 New version attached, fixing a context bug. There was a small bug in the previous version where, if context was set to 0, the all lines until the end of the last chunk were shown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 From noreply@sourceforge.net Tue May 13 04:55:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 20:55:20 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-688805 ] Iterator for gzip.GzipFile Message-ID: Feature Requests item #688805, was opened at 2003-02-18 10:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=688805&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) >Summary: Iterator for gzip.GzipFile Initial Comment: I'd like to request an iterator for gzlib, so that GzipFile objects can be treated like regular files, e.g.: gfile = gzlib.GzipFile(filename, 'r') for aline in gfile: # do stuff Here is a simple workaround that I use; this could be implemented in the gzlib itself, though I suspect there's a better way to do it (and if anybody cares to tell me what it is, I'd be happy to hear; I'm still finding my way around with generators and iterators): class FixGZip(gzip.GzipFile): """the GzipFile class normally does not have an iterator; add one""" def __iter__(self): def stopIter(): raise StopIteration while True: yield self.readline() or stopIter() ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 20:55 Message: Logged In: YES user_id=357491 This has been implemented. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=688805&group_id=5470 From noreply@sourceforge.net Tue May 13 04:58:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 20:58:04 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-692881 ] import files from any directory Message-ID: Feature Requests item #692881, was opened at 2003-02-25 05:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=692881&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: import files from any directory Initial Comment: Many times I have a .py file with some functions, which I want to import. However, its functionality is very specific, so I don't want to copy it to a directory where it will always be available as a module. If I start Python from the directory of the file, I can import it, but this is not always the case. I can use execfile(), but import is better since it runs the file in its own namespace. What I suggest is to extend the import statement syntax, to allow "module" to be a stringliteral as well as (identifier ".")* identifier. When it is a string literal, the string will be interpreted as the file name to import. The default name of the module will be the name which would import the file if its directory were in PYTHONPATH. If there is no such name, an exception will be raised if "as" is not used. For example, say the file with my functions is called "specific_functions.py" and sits in the directory "/dir". When I open the Python shell from the directory /dir, I can now call "import specific_functions". I suggest that this would do the same thing: "import 'specific_functions.py' ". When I open the Python shell from another directory, I currently have no simple way to import the file, but I suggest that I could use the command "import '/dir/specific_functions.py' ". The command "from '/dir/specific_functions.py' import *" should also work, of course. This has no backward compatibility issues as far as I can see, and is quite helpful, I think. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 20:58 Message: Logged In: YES user_id=357491 You can add the directory to sys.path and then do a normal import. ---------------------------------------------------------------------- Comment By: Alexander Rødseth (alexanro) Date: 2003-05-12 07:50 Message: Logged In: YES user_id=679374 Today, chances are quite good that a random downloaded python-script will function on any computer. This suggestion would increase the chances that one will get errors connected to "missing files" (from 0% to some%, which is a great deal). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=692881&group_id=5470 From noreply@sourceforge.net Tue May 13 05:04:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 21:04:56 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-449187 ] if x in 1,2,3: should work Message-ID: Feature Requests item #449187, was opened at 2001-08-08 11:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: if x in 1,2,3: should work Initial Comment: There is normally some symmetry between 'for x in whatever' and 'if x in whatever'. However, the symmetry is broken (for syntax reasons I do not understand) in one case, a tuple-without-parentheses: for x in 1, 2, 3: pass works fine, but if x in 1, 2, 3: pass gives a syntax error. Can the syntax error be removed? I think it violates the principle of least astonishment, as one would expect that either both forms would work or neither would. (I'd offer a patch, but I don't think I really understand the way Python syntax is implemented in the Python compiler...!-). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 23:04 Message: Logged In: YES user_id=80475 No dice, then non-parenthesis version occurs throughout Python (blame the comma, not the parens): t = 'a', 'b', 'c' # This works. return 'a', 'b', 'c' # So does this. for letter in 'a', 'b', 'c': So this should also. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 20:53 Message: Logged In: YES user_id=357491 That's why I want for to be changed so that it needs parentheses. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 20:38 Message: Logged In: YES user_id=31435 The fundamental problem is that, as an expression, "x in 1, 2, 3" doesn't group as an if-statement would need it to group: >>> y = 'a' in 'a', 'b', 'c' >>> y (True, 'b', 'c') >>> >>> for y in 'a' in 'a', 'b', 'c': ... print y ... True b c >>> So if Python did allow a testlist as the 'if' expression, it would be parsed as: if ((x in 1), 2, 3): which is a surprising way of raising TypeError. The parens are really needed to get the 1, 2, 3 part parsed as a tuple. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 20:11 Message: Logged In: YES user_id=357491 I didn't know Python accepted that 'for' structure!?! I agree with Alex that this should be changed at some point. As for why this is, it appears that the offending grammar definitions are: for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] testlist: test (',' test)* [','] test: and_test ('or' and_test)* | lambdef So it looks like the difference is 'for' uses testlist while 'if' uses just test. Probably can just swap out testlist for test and get the result you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 From noreply@sourceforge.net Tue May 13 06:34:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 12 May 2003 22:34:51 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-449187 ] if x in 1,2,3: should work Message-ID: Feature Requests item #449187, was opened at 2001-08-08 09:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: if x in 1,2,3: should work Initial Comment: There is normally some symmetry between 'for x in whatever' and 'if x in whatever'. However, the symmetry is broken (for syntax reasons I do not understand) in one case, a tuple-without-parentheses: for x in 1, 2, 3: pass works fine, but if x in 1, 2, 3: pass gives a syntax error. Can the syntax error be removed? I think it violates the principle of least astonishment, as one would expect that either both forms would work or neither would. (I'd offer a patch, but I don't think I really understand the way Python syntax is implemented in the Python compiler...!-). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-12 22:34 Message: Logged In: YES user_id=357491 Nuts. Oh well. Then should we close this RFE? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 21:04 Message: Logged In: YES user_id=80475 No dice, then non-parenthesis version occurs throughout Python (blame the comma, not the parens): t = 'a', 'b', 'c' # This works. return 'a', 'b', 'c' # So does this. for letter in 'a', 'b', 'c': So this should also. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:53 Message: Logged In: YES user_id=357491 That's why I want for to be changed so that it needs parentheses. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 18:38 Message: Logged In: YES user_id=31435 The fundamental problem is that, as an expression, "x in 1, 2, 3" doesn't group as an if-statement would need it to group: >>> y = 'a' in 'a', 'b', 'c' >>> y (True, 'b', 'c') >>> >>> for y in 'a' in 'a', 'b', 'c': ... print y ... True b c >>> So if Python did allow a testlist as the 'if' expression, it would be parsed as: if ((x in 1), 2, 3): which is a surprising way of raising TypeError. The parens are really needed to get the 1, 2, 3 part parsed as a tuple. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:11 Message: Logged In: YES user_id=357491 I didn't know Python accepted that 'for' structure!?! I agree with Alex that this should be changed at some point. As for why this is, it appears that the offending grammar definitions are: for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] testlist: test (',' test)* [','] test: and_test ('or' and_test)* | lambdef So it looks like the difference is 'for' uses testlist while 'if' uses just test. Probably can just swap out testlist for test and get the result you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 From noreply@sourceforge.net Tue May 13 08:01:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 00:01:39 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-447143 ] exception item from mapped function Message-ID: Feature Requests item #447143, was opened at 2001-08-02 13:37 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: exception item from mapped function Initial Comment: The purpose of this enhancement would be to get the item in a list that caused an exception when applying a mapped function. For instance, suppose that I want to detect if there is an item in a list that is not a number. For this illustration I try to map float on the list and then catch the exception. try: map(float, mylist) except ValueError: print "The item %s in mylist is not a number." % (my_item) The problem is that I do not know which item in the list caused the exception. How do I get my_item? This information could probably be useful in a number of different contexts. Thank you. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-13 09:01 Message: Logged In: YES user_id=89016 I we had exception chaining (i.e. each exception can reference another exception, that is the cause for this one), this would just be a special case. A traceback could then look like this: >>> map(float, [0, 1, None, 3]) Traceback (most recent call last): File "", line 1, in ? TypeError: in entry None at position 2 Caused by: TypeError: float() argument must be a string or a number ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 02:59 Message: Logged In: YES user_id=357491 Well, if you were doing this with a list comprehension it isn't hard:: try: float_list = [float(x) for x in mylist] except ValueError: print "The item %s in mylist is not a number." % x Since list comprehensions are practically just a 'for' loop in a much tighter way the variables used stick around just as if you had used a 'for' loop. The other issue is the way errors propogate in C. If map were to return its own error specifying which item caused a problem it would have to overwrite the exception that was raised in the first place and overwriting exceptions on the whole is bad. If you really are in love with map you can always define your own wrapper around float to raise the exception you want:: def myfloat(num): try: return float(num) except ValueError: raise ValueError("The item %s in mylist is not a number." % num) I personally feel this RFE should be rejected. Anyone else agree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 From noreply@sourceforge.net Tue May 13 08:04:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 00:04:28 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-447143 ] exception item from mapped function Message-ID: Feature Requests item #447143, was opened at 2001-08-02 04:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: exception item from mapped function Initial Comment: The purpose of this enhancement would be to get the item in a list that caused an exception when applying a mapped function. For instance, suppose that I want to detect if there is an item in a list that is not a number. For this illustration I try to map float on the list and then catch the exception. try: map(float, mylist) except ValueError: print "The item %s in mylist is not a number." % (my_item) The problem is that I do not know which item in the list caused the exception. How do I get my_item? This information could probably be useful in a number of different contexts. Thank you. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-13 00:04 Message: Logged In: YES user_id=357491 True. I remember this being discussed at one point and people thinking it was a good idea but it never got implemented. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-13 00:01 Message: Logged In: YES user_id=89016 I we had exception chaining (i.e. each exception can reference another exception, that is the cause for this one), this would just be a special case. A traceback could then look like this: >>> map(float, [0, 1, None, 3]) Traceback (most recent call last): File "", line 1, in ? TypeError: in entry None at position 2 Caused by: TypeError: float() argument must be a string or a number ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:59 Message: Logged In: YES user_id=357491 Well, if you were doing this with a list comprehension it isn't hard:: try: float_list = [float(x) for x in mylist] except ValueError: print "The item %s in mylist is not a number." % x Since list comprehensions are practically just a 'for' loop in a much tighter way the variables used stick around just as if you had used a 'for' loop. The other issue is the way errors propogate in C. If map were to return its own error specifying which item caused a problem it would have to overwrite the exception that was raised in the first place and overwriting exceptions on the whole is bad. If you really are in love with map you can always define your own wrapper around float to raise the exception you want:: def myfloat(num): try: return float(num) except ValueError: raise ValueError("The item %s in mylist is not a number." % num) I personally feel this RFE should be rejected. Anyone else agree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 From noreply@sourceforge.net Tue May 13 08:21:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 00:21:38 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-447143 ] exception item from mapped function Message-ID: Feature Requests item #447143, was opened at 2001-08-02 13:37 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: exception item from mapped function Initial Comment: The purpose of this enhancement would be to get the item in a list that caused an exception when applying a mapped function. For instance, suppose that I want to detect if there is an item in a list that is not a number. For this illustration I try to map float on the list and then catch the exception. try: map(float, mylist) except ValueError: print "The item %s in mylist is not a number." % (my_item) The problem is that I do not know which item in the list caused the exception. How do I get my_item? This information could probably be useful in a number of different contexts. Thank you. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-13 09:21 Message: Logged In: YES user_id=89016 I'm still planning to give this a try someday, but maybe this should be part of the big "new style exceptions PEP"? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 09:04 Message: Logged In: YES user_id=357491 True. I remember this being discussed at one point and people thinking it was a good idea but it never got implemented. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-13 09:01 Message: Logged In: YES user_id=89016 I we had exception chaining (i.e. each exception can reference another exception, that is the cause for this one), this would just be a special case. A traceback could then look like this: >>> map(float, [0, 1, None, 3]) Traceback (most recent call last): File "", line 1, in ? TypeError: in entry None at position 2 Caused by: TypeError: float() argument must be a string or a number ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 02:59 Message: Logged In: YES user_id=357491 Well, if you were doing this with a list comprehension it isn't hard:: try: float_list = [float(x) for x in mylist] except ValueError: print "The item %s in mylist is not a number." % x Since list comprehensions are practically just a 'for' loop in a much tighter way the variables used stick around just as if you had used a 'for' loop. The other issue is the way errors propogate in C. If map were to return its own error specifying which item caused a problem it would have to overwrite the exception that was raised in the first place and overwriting exceptions on the whole is bad. If you really are in love with map you can always define your own wrapper around float to raise the exception you want:: def myfloat(num): try: return float(num) except ValueError: raise ValueError("The item %s in mylist is not a number." % num) I personally feel this RFE should be rejected. Anyone else agree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 From noreply@sourceforge.net Tue May 13 08:57:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 00:57:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-736892 ] forcing function to act like an unbound method dumps core Message-ID: Bugs item #736892, was opened at 2003-05-13 00: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=736892&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Paul Du Bois (df-dubois) Assigned to: Nobody/Anonymous (nobody) Summary: forcing function to act like an unbound method dumps core Initial Comment: Using ActivePython, v2.2.2 I was reading PEP252 and trying stupid things, like this: k [ 0:51] 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. >>> def func(): pass ... >>> f = func.__get__() Traceback (most recent call last): File "", line 1, in ? TypeError: function takes at least 1 argument (0 given) >>> f = func.__get__(None) >>> f() # This gives a reasonable result Traceback (most recent call last): File "", line 1, in ? TypeError: unbound method func() must be called with ? instance as first argument (got nothing instead) >>> f(1) # This crashes accessing a null pointer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 From noreply@sourceforge.net Tue May 13 14:34:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 06:34:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-471893 ] Security review of pickle/marshal docs Message-ID: Bugs item #471893, was opened at 2001-10-16 18:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471893&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Security review of pickle/marshal docs Initial Comment: Paul Rubin points out that the security implications of using marshal and/or pickle aren't clear from the docs. Assigning to Jeremy as he's more sensitive to such issues than I am; maybe Barry would like to get paranoid too . A specific example: the pickle docs say that pickle doesn't support code objects, and "at least this avoids the possibility of smuggling Trojan horses into a program". However, 1) The marshal docs don't mention this vulnerability at all. while 2) The pickle docs don't spell out possible dangers due to things pickle does that marshal doesn't (like importing modules, and running class constructors). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 09:34 Message: Logged In: YES user_id=11375 Can I check this in? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-26 14:22 Message: Logged In: YES user_id=11375 OK; here's a reworked version that retitles the "Pickle security" section to "Subclassing Unpicklers", leaving the discussion of subclassing alone except for a few typo fixes. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-06 14:40 Message: Logged In: YES user_id=31435 I think there are several reasons to override these methods. The one most relevant to this bug report is that, while Python has stopped pretending that pickles are secure by default, the choke points are still there, and motivated users can still expolit them. For example, search pickle.py for __import__. The only occurrence of __import__ in the Unpickler class is in method find_class(), and that's by design. If a user overrides find_class(), the only imports the Unpickler *can* do are those the user explicitly performs in their own find_class() implementation. So if that's a notion of "security" a user is happy with, they can still have it. The docs trying to describe this are still valid. It's only the "by magic" safety checks that have gone away (and they were buggy anyway, so no loss). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-06 09:29 Message: Logged In: YES user_id=11375 The Cookie classes that use pickle have DeprecationWarnings in 2.3, and should disappear in 2.4. If {find,load}_global are still going to be supported, though, then they should still be documented (though, given that you shouldn't be unpickling untrusted data, why would you ever bother overriding find_global?) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-02-05 18:03 Message: Logged In: YES user_id=12800 I'll just mention that anybody using anything other than Cookie.SimpleCookie is insane, and even using the Cookie module at all to parse real-world cookies is mildly nuts because it's way too strict. I prefer m&m's in my cookies. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-05 17:57 Message: Logged In: YES user_id=31435 Andrew, didn't you go overboard in deleting text here? The __safe_for_unpickling__ check is gone in 2.3, but most of the rest of the text still applies. In particular, Cookie is still a problem for people inclined to worry about this, and overriding methods like find_global and load_global is still valuable stuff (the unpickler still never imports anything that doesn't come from an opcode triggering one of these methods). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-02-05 16:29 Message: Logged In: YES user_id=12800 Karmically (no, not comically) reassigning to Tim who started this whole thing, and who happens to be dumping his pickles these days. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-05 15:40 Message: Logged In: YES user_id=11375 Re-opening. With the changes to pickling in Python 2.3, the security material should be replaced with a warning to not unpickle untrusted data. Patch attached. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-18 11:08 Message: Logged In: YES user_id=12800 You're right of course. I meant to fix that and forgot. Will do so asap. Glad you like the rest of it, though! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-18 01:56 Message: Logged In: NO Barry - the new docs just went up and they're a big improvement over the old. However the sentence "The issue here is usually not that a class's constructor will get called -- it won't by the unpickler -- but that the class's destructor (i.e. its __del__() method) might get called when the object is garbage collected." isn't correct. There's a flag in the pickle stream that tells the unpickler that the pickler found a __getinitargs__ method at pickling time. If the flag is set in the pickle, then the unpickler calls the class constructor, whether there's a __getinitargs__ method in the class or not. The sample exploit that I posted earlier on, , is an example of an artificially concocted pickle that makes a class constructor get called. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-17 17:07 Message: Logged In: NO Are the new docs downloadable from somewhere? thanx --Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-15 19:43 Message: Logged In: NO Barry, can you also do something about the Cookie module, or at least about its documentation? If Cookie is aliased to SmartCookie, I think that needs mention. --Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-15 19:12 Message: Logged In: YES user_id=12800 I have rewritten the pickle documentation, and updated the marshal, cPickle, and copy_reg documentation. I believe all the documentation issues raised here have been fixed. Implementation issues will be pushed to Python 2.3, and the plan is to write a PEP to plan future work. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-13 16:39 Message: Logged In: YES user_id=12800 Assigning to Jeremy so he'll remember to forward me Jim's email. Jeremy can ping-pong it to Fred if he wants, and then reassign to me after forwarding the email. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-13 01:18 Message: Logged In: NO The find_global variable sounds encouraging and if it fixes this problem, that's great. I'd still feel better if the eval call goes away. Is removing it allowed under the 2.2 feature freeze? It doesn't affect anything visible, so no tests would have to change, etc. Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 19:38 Message: Logged In: NO It's possible that the eval is safe, but validating that takes a line by line code review of all the paths that evaling a string can go through. It's also brittle in that maybe someone will change the evaluator (say to support Perl-like interpolation) in a future Python version and not remember to change the unpickler. Something like that has already happened with the Cookie module. My guess is that it happened with the pickle module--the whole point of that quoted string check is that the original pickle implementer didn't trust the input. The stuff about unpickling class instances was added later (maybe by another person) without remembering the security issue. Using eval this way is like storing a vat of cyanide in your child's bedroom. Sure, maybe if you check the seals and locks on the vat carefully enough, you can convince yourself that your child won't be able to get to the cyanide. But wouldn't you feel safer just not having the vat there at all? That's basic safety-consciousness. Security consciousness works the same way. Try to keep dangerous ingredients and attackers as far away from each other as possible. Paul ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-12 13:52 Message: Logged In: YES user_id=31435 Why are people (Paul, Jeremy) concerned about eval'ing strings? cPickle and pickle both check that they're properly quoted, and this isn't sh or Perl: Python has no "dynamic" gimmicks buried in string literals. All eval'ing a string literal can do is produce a binary blob via interpeting simple escape sequences. They're like C strings this way -- maybe we'll run out of memory, but that's it. I would agree that Python should be refactored internally to supply a clean function for changing string literals into binary blobs, but that would be for clarity and efficiency, not security. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2001-11-12 13:14 Message: Logged In: YES user_id=73023 It sounds like there are some documentation bugs: - The security ramifications are not discussed, nor are the remedies. - The cPickle module isn't documented very well. I submitted some documentation a long time ago that never got incorporated AFAIK. I wish I still had it. :) - cPickle has a feature for turning off instance support and for restricting which classes can be unpickled. You can set the find_global attribute on a cPickle.Unpickler. The find_global attribute can be a function or None. If it is None, then no instances can be unpickled. If it is a function, then it should accept a module and name and return the corresponding global. It is responsible for looking up the global and can raise an error to prevent a global's use. See the ZEO storage server implementation for an example of using this hook. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 01:33 Message: Logged In: NO I like marshal and think it's much cleaner than pickle. I'd like to see its format cleaned up and documented so it can be a portable transport format. Even the recursion issue isn't so compelling--there's only a danger on marshalling, not unmarshalling, and the application has control over what it marshals. So I think the idea of documenting marshal (bug #467384) should be kept alive. However, it shouldn't be changed in 2.2. If the Cookie class is still really aliased by default to SmartCookie, that's a bad bug and should definitely be fixed ASAP. The Cookie docs clearly say not to use SmartCookie or SerialCookie. In fact I think SmartCookie and SerialCookie should be disabled altogether. Any applications using them on the open internet have a security but and should be fixed immediately. Here's a possible temporary approach to fixing SmartCookie and SerialCookie: append a cryptographic message authentication code (MAC) to each pickled cookie. That means the application has some secret string K as a configuration parameter (it should be 10 or more random 8-bit characters, or 20 or more random hex digits, etc). Then a smart cookie would be a pickle p, followed by SHA(p+K). The Cookie module would validate the MAC before calling unpickle, and raise an exception if the MAC wasn't valid. The security of this scheme rests on K being kept secret from attackers, which is generally not an easy thing to manage, but it's something to think about. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-10 17:07 Message: Logged In: YES user_id=31392 I don't think we should be doing anything about marshal. Maybe we should name in pyclib or something <0.9 wink>. It works fine for .pyc files, but I don't see a reason for it to do anymore than is necessary for that purpose. I think the notion of an unpickler that only handles builtin datatypes is the most attractive option you offer, but Paul has a good point about eval for strings. (It currently has some hacks that address specific exploits, but I doubt they are sufficient.) I also wonder how hard it is to handle builtin types and avoid subclasses of builtin types. If there are any changes to pickle, I think we need to be careful about how it is described. If we claim that an unpickler is safe for untrusted pickles, we've made a fairly strong claim. I still think such a design change requires a PEP that includes some requirements and use cases and a thorough analysis of potential exploits. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-10 14:42 Message: Logged In: NO See bug #467384 for discussion about marshal. Besides the recursion issue, marshal's format is explicitly undocumented and subject to change--you can't rely on it to interoperate between two different Python versions, so it's no good as an RPC serializer. The format has kludges (e.g. the representation of long ints) that make it undesirable to freeze and document it and force future versions to be backward compatible. Adding a pickle.loads flag to prevent instance unpickling isn't perfect but is probably the best alternative on your list. Perhaps the flag can have a value that allows unpickling the instances by restoring the instance attributes rather than calling the initializer. That's not always the right way to unpickle an instance (that's why the unpickler no longer works that way) but it's good enough a lot of the time. There's another issue with pickle/cPickle which is that they unpickle quoted strings by evaling them. This is scary. While I don't see an immediate exploit, I also haven't examined the 1000's of lines of code I'd need to examine to convince myself that there's NOT an exploit. I think the unpickler should be changed to never call eval but just parse the string as it needs to. Guido seemed to think pickle might have other possible exploits. I don't know what he had in mind but before declaring it safe for untrusted data I think it needs to be gone over with a fine toothed comb. Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-10 12:37 Message: Logged In: YES user_id=12800 I'm going to agree with Paul that this is a problem needing fixing, however there are really several issues. 1. Cookie module makes it too easy to code exploits. Cookie exports a class, also called Cookie, which is aliased to SmartCookie, so that a naive program will simply pass cookie data to Cookie.Cookie() and you're screwed. So, Cookie module's defaults should be for more security rather than less, and Cookie.Cookie should be aliased to SimpleCookie instead. 2. There is no built-in safe mechanism for de-serializing data from untrusted sources. You can't use pickle without overloading a "magic" method. You can't use cPickle because you can't do the overloading trick. You can't use marshal because it isn't bulletproof against recursive datastructures. So how /do/ you do it? I think it just may be serious enough to deal with in Python 2.2, and I volunteer to address it (so I'll steal this bug report). Without looking at the code, or the level of effort necessary, I would make the following suggestions: 1. Add to the public interface of pickle and cPickle, a flag that either disables the unpickling of instances altogether, or disables calling any code with unpickled data, e.g. constructors. 2. Fix marshal to be bulletproof against recursive datastructures. 3. Update the docs for both pickle/cPickle and marshal to explain how to safely write de-serializers of untrusted strings. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-09 04:21 Message: Logged In: NO Well, Guido and Tim agree with you that it's not a pickle bug. I still feel it is one, because its docs currently make you think you can securely load untrusted pickles, and because it's a natural, non-obscure thing to want to do (see pyro and the cookie module), but whatever. If it's not a code bug then I feel it's a significant functionality shortcoming in the python library. Pyro uses pickle to serialize data for RPC calls over the internet. A malicious client could make a hostile pickle take over the server. The cookie module lets web applications store user session state in browser cookies. Its SerialCookie and SmartCookie classes let you put arbitrary Python objects into the user session, and serializes them when pickle. Again, a malicious client can make a hostile pickle, send it in a cookie header to the http server, and take over the server when the application unpickles the cookie. The current documentation for the pickle module makes it very clear to me that the doc writer thought it was safe to unpickle untrusted cookies. If pickle wasn't designed for that, then there was a communication failure between the designer and the doc writer. Yes, I'm willing to help with a PEP for fixing this situation. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-08 12:37 Message: Logged In: YES user_id=31392 I don't think of the issue you describe as a bug in the code. You're suggesting a new feature for pickle. As far as I can tell, the original design requirements for pickle did not include the ability to securely load a pickle from an untrusted source. It may be a legitimate feature request, but it's too late to make it into Python 2.2. I suggest we look at the design issues for Python 2.3 and decide if it's a feature we want to support. I imagine a PEP may be necessary to lay out the issues and the solution. Do you want to have a hand in that PEP? I still don't understand what it means that Pyro and cookie were bit by a bug. It sounds like they were using pickle in ways that pickle was not intended to support. A careful analysis of how those two applications use pickle would be helpful for generating requirements. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-07 18:54 Message: Logged In: NO IMO it's a code bug that you can't unpickle strings from untrusted sources. Pyro and the cookie module are examples of programs that got bitten by this bug. Whether it's really a bug is a matter of opinion--I had a big email exchange with Guido and Tim about it, and they felt it was enough to fix the pickle documentation. Pickle has the same problem as cPickle, but with pickle you can subclass the pickler and override the method that unpickles class objects, and work around the (IMO) bug. The workaround doesn't help cPickle since cPickle can't be subclassed. See bug #467384 for some related discussion. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-07 17:02 Message: Logged In: YES user_id=31392 What's the code bug? Your last message has a lot of gloom and doom , but I'm not sure what specific problem you'd like to see fixed. Are you saying that something needs to be fixed in cPickle and not in pickle? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-07 15:08 Message: Logged In: NO Irmen de Jong points out that the standard cookie module uses pickling for serial and smart cookies. The 2.1.1 cookie module docs explicitly say not to use those classes because of the security hole--that they're provided for backward compatibility only (but with what?! Any server that uses those classes on open ports needs to be changed right away). Irmen's library, http://pyro.sourceforge.net, also uses unpickle insecurely (he's aware of this now and is figuring out a fix). IMO this is really a code bug rather than a documentation bug, and should be fixed in the code rather than the docs. Documenting the bug rather than fixing it leaves a deficiency in the Python library: obvious uses of pickling, like Pyro and the cookie module, can't be implemented using cPickle and have to resort to a slower Python deserializer, or use marshal and have possible compatibility problems between versions (and not be able to serialize class instances). Paul ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-16 19:06 Message: Logged In: YES user_id=72053 Certainly anyone unserializing potentially malicious data with pickle, marshal, or anything else, should check the results before doing anything dangerous with them (like executing code). However, unpickle can potentially do damage before it even returns, by creating loading modules and creating initialized class instances. So pickle.loads should never be used on untrusted strings, except possibly in a rexec wrapper (as proposed by Tim). Another possibility (also by Tim) is to override the load_inst method of the Pickler class, though I don't think you can do that for cPickle. A sample exploit for unpickle can be found at . Unpickling the test string runs penguin.__init__ contrary to the doc's saying no initialization unless there's a __getinitargs__ method in the class def. The "exploding penguin" class is artificial, but applications are vulnerable if there's an unsafe constructor anywhere in any class of the application or in the python library (example: the NNTP constructor opens an IP connection to an arbitrary address, so a malicious imported string can send a message through your firewall when you import it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471893&group_id=5470 From noreply@sourceforge.net Tue May 13 14:34:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 06:34:34 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-453506 ] lists should have a copy method Message-ID: Feature Requests item #453506, was opened at 2001-08-20 17:23 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 1 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: lists should have a copy method Initial Comment: This is per someone on comp.os.python. It's odd that dictionaries have a copy method (you can say dict.copy()) but to copy a list you have to say list[:] or use copy.copy. I think list.copy() should be added for consistency. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-13 09:34 Message: Logged In: YES user_id=6380 Intuitive, schmuitive. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 21:57 Message: Logged In: YES user_id=31435 Assigned to Guido for rejection . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:46 Message: Logged In: YES user_id=357491 I'm with Tim; you don't need seven ways to copy (Tim forgot using a list comprehension and ``map(None, list)`` =). I say this RFE gets rejected. ---------------------------------------------------------------------- Comment By: Jesper Hertel (jhmagnus) Date: 2003-01-21 09:30 Message: Logged In: YES user_id=592328 I agree that it would be nice (and consistent) if lists had a copy() method. It would be more convenient. It is always tiresome to have to import modules to do simple stuff like this. The list[:] is a trick that you have to know before you can use it (it doesn't seem obvious to me), but list.copy() seems intuitive to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-23 01:43 Message: Logged In: YES user_id=31435 I doubt Guido would go for it. dicts grew a .copy() method *because* there was no convenient syntax like list[:] that worked for dicts. That's not a reason to add a .copy() method to lists too. Note that if you're too fond of uniformity , don't use any of these: use copy.copy() or copy.deepcopy(). Python doesn't need four ways to spell "copy this list". Oops: make that five. list (somelist) also copies a list. In 2.2, dict(somedict) also copies a dict. Enough already. ---------------------------------------------------------------------- Comment By: Michael Gilfix (mgilfix) Date: 2002-04-22 23:53 Message: Logged In: YES user_id=116038 What's the status of this? It seems pretty useful. I could submit a patch if someone likes... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 From noreply@sourceforge.net Tue May 13 15:01:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 07:01:40 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-453506 ] lists should have a copy method Message-ID: Feature Requests item #453506, was opened at 2001-08-20 23:23 Message generated for change (Comment added) made by jhmagnus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Rejected Priority: 1 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: lists should have a copy method Initial Comment: This is per someone on comp.os.python. It's odd that dictionaries have a copy method (you can say dict.copy()) but to copy a list you have to say list[:] or use copy.copy. I think list.copy() should be added for consistency. ---------------------------------------------------------------------- Comment By: Jesper Hertel (jhmagnus) Date: 2003-05-13 16:01 Message: Logged In: YES user_id=592328 What does schmuitive mean? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-13 15:34 Message: Logged In: YES user_id=6380 Intuitive, schmuitive. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-13 03:57 Message: Logged In: YES user_id=31435 Assigned to Guido for rejection . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 03:46 Message: Logged In: YES user_id=357491 I'm with Tim; you don't need seven ways to copy (Tim forgot using a list comprehension and ``map(None, list)`` =). I say this RFE gets rejected. ---------------------------------------------------------------------- Comment By: Jesper Hertel (jhmagnus) Date: 2003-01-21 15:30 Message: Logged In: YES user_id=592328 I agree that it would be nice (and consistent) if lists had a copy() method. It would be more convenient. It is always tiresome to have to import modules to do simple stuff like this. The list[:] is a trick that you have to know before you can use it (it doesn't seem obvious to me), but list.copy() seems intuitive to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-23 07:43 Message: Logged In: YES user_id=31435 I doubt Guido would go for it. dicts grew a .copy() method *because* there was no convenient syntax like list[:] that worked for dicts. That's not a reason to add a .copy() method to lists too. Note that if you're too fond of uniformity , don't use any of these: use copy.copy() or copy.deepcopy(). Python doesn't need four ways to spell "copy this list". Oops: make that five. list (somelist) also copies a list. In 2.2, dict(somedict) also copies a dict. Enough already. ---------------------------------------------------------------------- Comment By: Michael Gilfix (mgilfix) Date: 2002-04-23 05:53 Message: Logged In: YES user_id=116038 What's the status of this? It seems pretty useful. I could submit a patch if someone likes... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 From noreply@sourceforge.net Tue May 13 15:16:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 07:16:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-729817 ] rexec not listed as dead Message-ID: Bugs item #729817, was opened at 2003-04-29 16:01 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729817&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: rexec not listed as dead Initial Comment: The docs for 2.3b1 still list rexec as a valid module (although with some warnings of known vulnerabilities). However, the rexec module has apparently been killed (according to the what's new and to my tests of 2.3b1). -- Russell ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:16 Message: Logged In: YES user_id=11375 I've updated the docs in CVS; thanks for pointing this out! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729817&group_id=5470 From noreply@sourceforge.net Tue May 13 15:20:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 07:20:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-734806 ] telnetlib.read_until: float req'd for timeout Message-ID: Bugs item #734806, was opened at 2003-05-08 14:27 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734806&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Craig Allen (cba037) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.read_until: float req'd for timeout Initial Comment: The read_until (and I assume expect) method(s) have an optional timeout parameter; a float is required but this is not documented; use of an integer causes an exception. Documentation needs to mention the need for a float value (alternatively, telnetlib should convert to a float). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:20 Message: Logged In: YES user_id=11375 I can't replicate this; an integer value seems to work fine for me. Can you provide a test program that manifests the problem? And what exception and traceback do you get? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734806&group_id=5470 From noreply@sourceforge.net Tue May 13 15:28:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 07:28:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-729297 ] What's new in Python2.3b1 HTML generation. Message-ID: Bugs item #729297, was opened at 2003-04-28 22:07 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729297&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexis Layton (alayton) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: What's new in Python2.3b1 HTML generation. Initial Comment: Whenever a section name includes a style change, the llinks generated for it are truncated. To reproduce: Go to section "5. PEP 278: Universal New Line Support" Notice the next link: "6. PEP 279: The". The link should read "6. PEP 279: The enumerate() Built-In Function." Similar problems happen with links for sections 7 and 8. This problem does not happen in the table of contents however. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:28 Message: Logged In: YES user_id=11375 I've fixed the section headers in the "What's New" documents to not use markup. Fred, you can either fix the problem or just forget it and close the bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 01:05 Message: Logged In: YES user_id=80475 It looks like it is always grabbing the first word even when there is no style change. Looking back at Py2.2.2, it also occurred there. I'm this it is a TeX macro issue for Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729297&group_id=5470 From noreply@sourceforge.net Tue May 13 15:41:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 07:41:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-732124 ] Clarification of "pos" and "endpos" for match objects. Message-ID: Bugs item #732124, was opened at 2003-05-04 06:03 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732124&group_id=5470 Category: Documentation Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Philip Jägenstedt (foolip) Assigned to: Nobody/Anonymous (nobody) Summary: Clarification of "pos" and "endpos" for match objects. Initial Comment: In doc/python2.2/html/lib/match-objects.html the following is stated: pos The value of pos which was passed to the search() or match() function. ... endpos The value of endpos which was passed to the search() or match() function. ... I was confused for quite a while when I couldn't see a pos or endpos argument in the docs for match() in the re module. The said arguments exist only for "4.2.4 Regular Expression Objects", so I would suggest that it is clarified in the match-object docs when the pos and endpos members are available. I guess that would mean writing "procedure" instead of "function" too, but more importantly, a formulation like "The value of pos which was passed to the search() or match() procedure of the regexp object" That is all. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:41 Message: Logged In: YES user_id=11375 Fixed in CVS; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732124&group_id=5470 From noreply@sourceforge.net Tue May 13 15:53:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 07:53:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-724767 ] Minor /Tools/Scripts/crlf.py bugs Message-ID: Bugs item #724767, was opened at 2003-04-20 18:09 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470 >Category: Demos and Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: logistix (logistix) >Assigned to: A.M. Kuchling (akuchling) Summary: Minor /Tools/Scripts/crlf.py bugs Initial Comment: Caught these when I tried to cut-and-paste the code. crlf.py uses the variable name file, which it shouldn't anymore. I've attached a patch to fix this problem. It also looks like the method of determining if a file is text or binary isn't unicode safe. Am I right? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:53 Message: Logged In: YES user_id=11375 Fixed (though I changed the variable name to 'filename', not 'file_'.) Yes, it won't be Unicode-safe if the file is in a 16-bit encoding such as UCS-2. It'll be fine for other encodings; for example, UTF-8 wouldn't be a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470 From noreply@sourceforge.net Tue May 13 15:57:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 07:57:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-723287 ] add timeout support in socket using modules Message-ID: Bugs item #723287, was opened at 2003-04-17 14:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723287&group_id=5470 Category: Python Library Group: Feature Request >Status: Closed Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: add timeout support in socket using modules Initial Comment: Now that Skip has fixed the socket.settimeout() issue for sockets as files (bug 707074), it would be nice if the higher level modules had options for setting socket timeouts. I'm thinking of httplib, smtplib, nntplib, et al. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:57 Message: Logged In: YES user_id=11375 Adding to PEP 42 for a permanent record and closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723287&group_id=5470 From noreply@sourceforge.net Tue May 13 16:02:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 08:02:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-713722 ] Distutils documentation amputated Message-ID: Bugs item #713722, was opened at 2003-04-02 01:27 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713722&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory Ewing (gcewing) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils documentation amputated Initial Comment: Somewhere between the 2.0 and 2.1 documentation releases, a big chunk of the Distributing Python Modules manual seems to have gone missing. Section 7 (Examples), 8 (Extending the Distutils) and most of 9 (Reference) are absent. Section 7 contains a small part of what used to be section 9. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 11:02 Message: Logged In: YES user_id=11375 I've deleted the dangling references to the missing sections. ---------------------------------------------------------------------- Comment By: Gregory Ewing (gcewing) Date: 2003-05-05 02:12 Message: Logged In: YES user_id=747684 You're right! I never thought to look any further than the contents page. I guess there's not much that can be done, then. But perhaps at least there should be an "Extending the Distutils" heading which says "Not written yet" or some such, because other parts of the docs make explicit reference to this section! ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-03 17:57 Message: Logged In: YES user_id=31392 Can you be specific about what text was lost? That is, what revision of dist.tex contains the text that is missing? If I look at the 2.0 release documentation, I see an empty section named "Extending the distutils." I don't think there was ever any text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713722&group_id=5470 From noreply@sourceforge.net Tue May 13 16:07:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 08:07:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-724767 ] Minor /Tools/Scripts/crlf.py bugs Message-ID: Bugs item #724767, was opened at 2003-04-20 17:09 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470 Category: Demos and Tools Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: logistix (logistix) Assigned to: A.M. Kuchling (akuchling) Summary: Minor /Tools/Scripts/crlf.py bugs Initial Comment: Caught these when I tried to cut-and-paste the code. crlf.py uses the variable name file, which it shouldn't anymore. I've attached a patch to fix this problem. It also looks like the method of determining if a file is text or binary isn't unicode safe. Am I right? ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2003-05-13 10:07 Message: Logged In: YES user_id=699438 I realized a few days ago that lfcr.py has the same problem. I doubt you need it, but I can submit another patch if necessary. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 09:53 Message: Logged In: YES user_id=11375 Fixed (though I changed the variable name to 'filename', not 'file_'.) Yes, it won't be Unicode-safe if the file is in a 16-bit encoding such as UCS-2. It'll be fine for other encodings; for example, UTF-8 wouldn't be a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470 From noreply@sourceforge.net Tue May 13 16:45:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 08:45:23 -0700 Subject: [Python-bugs-list] [ 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: Open 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-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@sourceforge.net Tue May 13 16:53:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 08:53:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-737127 ] time.mktime() year < 1969 broken? time.accept2dyear=0 Message-ID: Bugs item #737127, was opened at 2003-05-13 11:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737127&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rich Landers (rt_landers) Assigned to: Nobody/Anonymous (nobody) Summary: time.mktime() year < 1969 broken? time.accept2dyear=0 Initial Comment: I cant seem to get years < 1970 to be accepted by time.mktime() under ANY circumstances. From the module-time documentation, I thought they should work if I set time.accept2dyear= 0 and/or used 4-digit years. My platform is Python 2.2.2 on Windows 2000. I also have Mark Hammond's "win32all-152" installed. The attached test behaves the same way on Python 2.2.1 on Linux (RedHat 8.0) Summary: time.accept2dyear = 0 tmtuple = [1969, 1, 1, 0, 0, 0, 0, 1, -1] time.mktime(tmtuple) = Traceback (most recent call last): File "timetest.py", line 24, in testMkTime print 'time.mktime(tmtuple) = ', time.mktime(tmtuple) OverflowError: mktime argument out of range ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737127&group_id=5470 From noreply@sourceforge.net Tue May 13 17:32:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 09:32:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-737127 ] time.mktime() year < 1969 broken? time.accept2dyear=0 Message-ID: Bugs item #737127, was opened at 2003-05-13 11:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737127&group_id=5470 >Category: Windows >Group: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Rich Landers (rt_landers) >Assigned to: Tim Peters (tim_one) Summary: time.mktime() year < 1969 broken? time.accept2dyear=0 Initial Comment: I cant seem to get years < 1970 to be accepted by time.mktime() under ANY circumstances. From the module-time documentation, I thought they should work if I set time.accept2dyear= 0 and/or used 4-digit years. My platform is Python 2.2.2 on Windows 2000. I also have Mark Hammond's "win32all-152" installed. The attached test behaves the same way on Python 2.2.1 on Linux (RedHat 8.0) Summary: time.accept2dyear = 0 tmtuple = [1969, 1, 1, 0, 0, 0, 0, 1, -1] time.mktime(tmtuple) = Traceback (most recent call last): File "timetest.py", line 24, in testMkTime print 'time.mktime(tmtuple) = ', time.mktime(tmtuple) OverflowError: mktime argument out of range ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-13 12:32 Message: Logged In: YES user_id=31435 Sorry, you're seeing a limitation of the platform mktime() implementation. Do a google search for "mktime msdn". The top hit will take you to the Microsoft docs for their mktime() implementation. The year restrictions are documented there, and Python inherits them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737127&group_id=5470 From noreply@sourceforge.net Tue May 13 18:13:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 10:13:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-724767 ] Minor /Tools/Scripts/crlf.py bugs Message-ID: Bugs item #724767, was opened at 2003-04-20 18:09 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470 Category: Demos and Tools Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: logistix (logistix) Assigned to: A.M. Kuchling (akuchling) Summary: Minor /Tools/Scripts/crlf.py bugs Initial Comment: Caught these when I tried to cut-and-paste the code. crlf.py uses the variable name file, which it shouldn't anymore. I've attached a patch to fix this problem. It also looks like the method of determining if a file is text or binary isn't unicode safe. Am I right? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 13:13 Message: Logged In: YES user_id=11375 Fixed; thanks! I'll go grepping for more cases. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-05-13 11:07 Message: Logged In: YES user_id=699438 I realized a few days ago that lfcr.py has the same problem. I doubt you need it, but I can submit another patch if necessary. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:53 Message: Logged In: YES user_id=11375 Fixed (though I changed the variable name to 'filename', not 'file_'.) Yes, it won't be Unicode-safe if the file is in a 16-bit encoding such as UCS-2. It'll be fine for other encodings; for example, UTF-8 wouldn't be a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470 From noreply@sourceforge.net Tue May 13 18:54:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 10:54:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: Bugs item #737202, was opened at 2003-05-13 19: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=737202&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply@sourceforge.net Tue May 13 19:16:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 11:16:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-724767 ] Minor /Tools/Scripts/crlf.py bugs Message-ID: Bugs item #724767, was opened at 2003-04-20 18:09 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470 Category: Demos and Tools Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: logistix (logistix) Assigned to: A.M. Kuchling (akuchling) Summary: Minor /Tools/Scripts/crlf.py bugs Initial Comment: Caught these when I tried to cut-and-paste the code. crlf.py uses the variable name file, which it shouldn't anymore. I've attached a patch to fix this problem. It also looks like the method of determining if a file is text or binary isn't unicode safe. Am I right? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 14:16 Message: Logged In: YES user_id=11375 Fixed; thanks! I'll go grepping for more cases. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 13:13 Message: Logged In: YES user_id=11375 Fixed; thanks! I'll go grepping for more cases. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-05-13 11:07 Message: Logged In: YES user_id=699438 I realized a few days ago that lfcr.py has the same problem. I doubt you need it, but I can submit another patch if necessary. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:53 Message: Logged In: YES user_id=11375 Fixed (though I changed the variable name to 'filename', not 'file_'.) Yes, it won't be Unicode-safe if the file is in a 16-bit encoding such as UCS-2. It'll be fine for other encodings; for example, UTF-8 wouldn't be a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724767&group_id=5470 From noreply@sourceforge.net Tue May 13 19:27:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 11:27:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-736892 ] forcing function to act like an unbound method dumps core Message-ID: Bugs item #736892, was opened at 2003-05-13 03:57 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Paul Du Bois (df-dubois) Assigned to: Nobody/Anonymous (nobody) Summary: forcing function to act like an unbound method dumps core Initial Comment: Using ActivePython, v2.2.2 I was reading PEP252 and trying stupid things, like this: k [ 0:51] 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. >>> def func(): pass ... >>> f = func.__get__() Traceback (most recent call last): File "", line 1, in ? TypeError: function takes at least 1 argument (0 given) >>> f = func.__get__(None) >>> f() # This gives a reasonable result Traceback (most recent call last): File "", line 1, in ? TypeError: unbound method func() must be called with ? instance as first argument (got nothing instead) >>> f(1) # This crashes accessing a null pointer ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 14:27 Message: Logged In: YES user_id=11375 It seems to be fixed in 2.3CVS: >>> f = func.__get__(None) Traceback (most recent call last): File "", line 1, in ? TypeError: __get__(None, None) is invalid The fix needs to be backported to the 2.2 branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 From noreply@sourceforge.net Tue May 13 19:48:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 11:48:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-471893 ] Security review of pickle/marshal docs Message-ID: Bugs item #471893, was opened at 2001-10-16 18:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471893&group_id=5470 Category: Extension Modules Group: None Status: Open >Resolution: Accepted Priority: 7 Submitted By: Tim Peters (tim_one) >Assigned to: A.M. Kuchling (akuchling) Summary: Security review of pickle/marshal docs Initial Comment: Paul Rubin points out that the security implications of using marshal and/or pickle aren't clear from the docs. Assigning to Jeremy as he's more sensitive to such issues than I am; maybe Barry would like to get paranoid too . A specific example: the pickle docs say that pickle doesn't support code objects, and "at least this avoids the possibility of smuggling Trojan horses into a program". However, 1) The marshal docs don't mention this vulnerability at all. while 2) The pickle docs don't spell out possible dangers due to things pickle does that marshal doesn't (like importing modules, and running class constructors). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-13 14:48 Message: Logged In: YES user_id=31435 Yes, please do! And thank you. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 09:34 Message: Logged In: YES user_id=11375 Can I check this in? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-26 14:22 Message: Logged In: YES user_id=11375 OK; here's a reworked version that retitles the "Pickle security" section to "Subclassing Unpicklers", leaving the discussion of subclassing alone except for a few typo fixes. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-06 14:40 Message: Logged In: YES user_id=31435 I think there are several reasons to override these methods. The one most relevant to this bug report is that, while Python has stopped pretending that pickles are secure by default, the choke points are still there, and motivated users can still expolit them. For example, search pickle.py for __import__. The only occurrence of __import__ in the Unpickler class is in method find_class(), and that's by design. If a user overrides find_class(), the only imports the Unpickler *can* do are those the user explicitly performs in their own find_class() implementation. So if that's a notion of "security" a user is happy with, they can still have it. The docs trying to describe this are still valid. It's only the "by magic" safety checks that have gone away (and they were buggy anyway, so no loss). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-06 09:29 Message: Logged In: YES user_id=11375 The Cookie classes that use pickle have DeprecationWarnings in 2.3, and should disappear in 2.4. If {find,load}_global are still going to be supported, though, then they should still be documented (though, given that you shouldn't be unpickling untrusted data, why would you ever bother overriding find_global?) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-02-05 18:03 Message: Logged In: YES user_id=12800 I'll just mention that anybody using anything other than Cookie.SimpleCookie is insane, and even using the Cookie module at all to parse real-world cookies is mildly nuts because it's way too strict. I prefer m&m's in my cookies. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-05 17:57 Message: Logged In: YES user_id=31435 Andrew, didn't you go overboard in deleting text here? The __safe_for_unpickling__ check is gone in 2.3, but most of the rest of the text still applies. In particular, Cookie is still a problem for people inclined to worry about this, and overriding methods like find_global and load_global is still valuable stuff (the unpickler still never imports anything that doesn't come from an opcode triggering one of these methods). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-02-05 16:29 Message: Logged In: YES user_id=12800 Karmically (no, not comically) reassigning to Tim who started this whole thing, and who happens to be dumping his pickles these days. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-05 15:40 Message: Logged In: YES user_id=11375 Re-opening. With the changes to pickling in Python 2.3, the security material should be replaced with a warning to not unpickle untrusted data. Patch attached. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-18 11:08 Message: Logged In: YES user_id=12800 You're right of course. I meant to fix that and forgot. Will do so asap. Glad you like the rest of it, though! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-18 01:56 Message: Logged In: NO Barry - the new docs just went up and they're a big improvement over the old. However the sentence "The issue here is usually not that a class's constructor will get called -- it won't by the unpickler -- but that the class's destructor (i.e. its __del__() method) might get called when the object is garbage collected." isn't correct. There's a flag in the pickle stream that tells the unpickler that the pickler found a __getinitargs__ method at pickling time. If the flag is set in the pickle, then the unpickler calls the class constructor, whether there's a __getinitargs__ method in the class or not. The sample exploit that I posted earlier on, , is an example of an artificially concocted pickle that makes a class constructor get called. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-17 17:07 Message: Logged In: NO Are the new docs downloadable from somewhere? thanx --Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-15 19:43 Message: Logged In: NO Barry, can you also do something about the Cookie module, or at least about its documentation? If Cookie is aliased to SmartCookie, I think that needs mention. --Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-15 19:12 Message: Logged In: YES user_id=12800 I have rewritten the pickle documentation, and updated the marshal, cPickle, and copy_reg documentation. I believe all the documentation issues raised here have been fixed. Implementation issues will be pushed to Python 2.3, and the plan is to write a PEP to plan future work. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-13 16:39 Message: Logged In: YES user_id=12800 Assigning to Jeremy so he'll remember to forward me Jim's email. Jeremy can ping-pong it to Fred if he wants, and then reassign to me after forwarding the email. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-13 01:18 Message: Logged In: NO The find_global variable sounds encouraging and if it fixes this problem, that's great. I'd still feel better if the eval call goes away. Is removing it allowed under the 2.2 feature freeze? It doesn't affect anything visible, so no tests would have to change, etc. Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 19:38 Message: Logged In: NO It's possible that the eval is safe, but validating that takes a line by line code review of all the paths that evaling a string can go through. It's also brittle in that maybe someone will change the evaluator (say to support Perl-like interpolation) in a future Python version and not remember to change the unpickler. Something like that has already happened with the Cookie module. My guess is that it happened with the pickle module--the whole point of that quoted string check is that the original pickle implementer didn't trust the input. The stuff about unpickling class instances was added later (maybe by another person) without remembering the security issue. Using eval this way is like storing a vat of cyanide in your child's bedroom. Sure, maybe if you check the seals and locks on the vat carefully enough, you can convince yourself that your child won't be able to get to the cyanide. But wouldn't you feel safer just not having the vat there at all? That's basic safety-consciousness. Security consciousness works the same way. Try to keep dangerous ingredients and attackers as far away from each other as possible. Paul ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-12 13:52 Message: Logged In: YES user_id=31435 Why are people (Paul, Jeremy) concerned about eval'ing strings? cPickle and pickle both check that they're properly quoted, and this isn't sh or Perl: Python has no "dynamic" gimmicks buried in string literals. All eval'ing a string literal can do is produce a binary blob via interpeting simple escape sequences. They're like C strings this way -- maybe we'll run out of memory, but that's it. I would agree that Python should be refactored internally to supply a clean function for changing string literals into binary blobs, but that would be for clarity and efficiency, not security. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2001-11-12 13:14 Message: Logged In: YES user_id=73023 It sounds like there are some documentation bugs: - The security ramifications are not discussed, nor are the remedies. - The cPickle module isn't documented very well. I submitted some documentation a long time ago that never got incorporated AFAIK. I wish I still had it. :) - cPickle has a feature for turning off instance support and for restricting which classes can be unpickled. You can set the find_global attribute on a cPickle.Unpickler. The find_global attribute can be a function or None. If it is None, then no instances can be unpickled. If it is a function, then it should accept a module and name and return the corresponding global. It is responsible for looking up the global and can raise an error to prevent a global's use. See the ZEO storage server implementation for an example of using this hook. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 01:33 Message: Logged In: NO I like marshal and think it's much cleaner than pickle. I'd like to see its format cleaned up and documented so it can be a portable transport format. Even the recursion issue isn't so compelling--there's only a danger on marshalling, not unmarshalling, and the application has control over what it marshals. So I think the idea of documenting marshal (bug #467384) should be kept alive. However, it shouldn't be changed in 2.2. If the Cookie class is still really aliased by default to SmartCookie, that's a bad bug and should definitely be fixed ASAP. The Cookie docs clearly say not to use SmartCookie or SerialCookie. In fact I think SmartCookie and SerialCookie should be disabled altogether. Any applications using them on the open internet have a security but and should be fixed immediately. Here's a possible temporary approach to fixing SmartCookie and SerialCookie: append a cryptographic message authentication code (MAC) to each pickled cookie. That means the application has some secret string K as a configuration parameter (it should be 10 or more random 8-bit characters, or 20 or more random hex digits, etc). Then a smart cookie would be a pickle p, followed by SHA(p+K). The Cookie module would validate the MAC before calling unpickle, and raise an exception if the MAC wasn't valid. The security of this scheme rests on K being kept secret from attackers, which is generally not an easy thing to manage, but it's something to think about. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-10 17:07 Message: Logged In: YES user_id=31392 I don't think we should be doing anything about marshal. Maybe we should name in pyclib or something <0.9 wink>. It works fine for .pyc files, but I don't see a reason for it to do anymore than is necessary for that purpose. I think the notion of an unpickler that only handles builtin datatypes is the most attractive option you offer, but Paul has a good point about eval for strings. (It currently has some hacks that address specific exploits, but I doubt they are sufficient.) I also wonder how hard it is to handle builtin types and avoid subclasses of builtin types. If there are any changes to pickle, I think we need to be careful about how it is described. If we claim that an unpickler is safe for untrusted pickles, we've made a fairly strong claim. I still think such a design change requires a PEP that includes some requirements and use cases and a thorough analysis of potential exploits. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-10 14:42 Message: Logged In: NO See bug #467384 for discussion about marshal. Besides the recursion issue, marshal's format is explicitly undocumented and subject to change--you can't rely on it to interoperate between two different Python versions, so it's no good as an RPC serializer. The format has kludges (e.g. the representation of long ints) that make it undesirable to freeze and document it and force future versions to be backward compatible. Adding a pickle.loads flag to prevent instance unpickling isn't perfect but is probably the best alternative on your list. Perhaps the flag can have a value that allows unpickling the instances by restoring the instance attributes rather than calling the initializer. That's not always the right way to unpickle an instance (that's why the unpickler no longer works that way) but it's good enough a lot of the time. There's another issue with pickle/cPickle which is that they unpickle quoted strings by evaling them. This is scary. While I don't see an immediate exploit, I also haven't examined the 1000's of lines of code I'd need to examine to convince myself that there's NOT an exploit. I think the unpickler should be changed to never call eval but just parse the string as it needs to. Guido seemed to think pickle might have other possible exploits. I don't know what he had in mind but before declaring it safe for untrusted data I think it needs to be gone over with a fine toothed comb. Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-10 12:37 Message: Logged In: YES user_id=12800 I'm going to agree with Paul that this is a problem needing fixing, however there are really several issues. 1. Cookie module makes it too easy to code exploits. Cookie exports a class, also called Cookie, which is aliased to SmartCookie, so that a naive program will simply pass cookie data to Cookie.Cookie() and you're screwed. So, Cookie module's defaults should be for more security rather than less, and Cookie.Cookie should be aliased to SimpleCookie instead. 2. There is no built-in safe mechanism for de-serializing data from untrusted sources. You can't use pickle without overloading a "magic" method. You can't use cPickle because you can't do the overloading trick. You can't use marshal because it isn't bulletproof against recursive datastructures. So how /do/ you do it? I think it just may be serious enough to deal with in Python 2.2, and I volunteer to address it (so I'll steal this bug report). Without looking at the code, or the level of effort necessary, I would make the following suggestions: 1. Add to the public interface of pickle and cPickle, a flag that either disables the unpickling of instances altogether, or disables calling any code with unpickled data, e.g. constructors. 2. Fix marshal to be bulletproof against recursive datastructures. 3. Update the docs for both pickle/cPickle and marshal to explain how to safely write de-serializers of untrusted strings. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-09 04:21 Message: Logged In: NO Well, Guido and Tim agree with you that it's not a pickle bug. I still feel it is one, because its docs currently make you think you can securely load untrusted pickles, and because it's a natural, non-obscure thing to want to do (see pyro and the cookie module), but whatever. If it's not a code bug then I feel it's a significant functionality shortcoming in the python library. Pyro uses pickle to serialize data for RPC calls over the internet. A malicious client could make a hostile pickle take over the server. The cookie module lets web applications store user session state in browser cookies. Its SerialCookie and SmartCookie classes let you put arbitrary Python objects into the user session, and serializes them when pickle. Again, a malicious client can make a hostile pickle, send it in a cookie header to the http server, and take over the server when the application unpickles the cookie. The current documentation for the pickle module makes it very clear to me that the doc writer thought it was safe to unpickle untrusted cookies. If pickle wasn't designed for that, then there was a communication failure between the designer and the doc writer. Yes, I'm willing to help with a PEP for fixing this situation. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-08 12:37 Message: Logged In: YES user_id=31392 I don't think of the issue you describe as a bug in the code. You're suggesting a new feature for pickle. As far as I can tell, the original design requirements for pickle did not include the ability to securely load a pickle from an untrusted source. It may be a legitimate feature request, but it's too late to make it into Python 2.2. I suggest we look at the design issues for Python 2.3 and decide if it's a feature we want to support. I imagine a PEP may be necessary to lay out the issues and the solution. Do you want to have a hand in that PEP? I still don't understand what it means that Pyro and cookie were bit by a bug. It sounds like they were using pickle in ways that pickle was not intended to support. A careful analysis of how those two applications use pickle would be helpful for generating requirements. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-07 18:54 Message: Logged In: NO IMO it's a code bug that you can't unpickle strings from untrusted sources. Pyro and the cookie module are examples of programs that got bitten by this bug. Whether it's really a bug is a matter of opinion--I had a big email exchange with Guido and Tim about it, and they felt it was enough to fix the pickle documentation. Pickle has the same problem as cPickle, but with pickle you can subclass the pickler and override the method that unpickles class objects, and work around the (IMO) bug. The workaround doesn't help cPickle since cPickle can't be subclassed. See bug #467384 for some related discussion. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-07 17:02 Message: Logged In: YES user_id=31392 What's the code bug? Your last message has a lot of gloom and doom , but I'm not sure what specific problem you'd like to see fixed. Are you saying that something needs to be fixed in cPickle and not in pickle? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-07 15:08 Message: Logged In: NO Irmen de Jong points out that the standard cookie module uses pickling for serial and smart cookies. The 2.1.1 cookie module docs explicitly say not to use those classes because of the security hole--that they're provided for backward compatibility only (but with what?! Any server that uses those classes on open ports needs to be changed right away). Irmen's library, http://pyro.sourceforge.net, also uses unpickle insecurely (he's aware of this now and is figuring out a fix). IMO this is really a code bug rather than a documentation bug, and should be fixed in the code rather than the docs. Documenting the bug rather than fixing it leaves a deficiency in the Python library: obvious uses of pickling, like Pyro and the cookie module, can't be implemented using cPickle and have to resort to a slower Python deserializer, or use marshal and have possible compatibility problems between versions (and not be able to serialize class instances). Paul ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-16 19:06 Message: Logged In: YES user_id=72053 Certainly anyone unserializing potentially malicious data with pickle, marshal, or anything else, should check the results before doing anything dangerous with them (like executing code). However, unpickle can potentially do damage before it even returns, by creating loading modules and creating initialized class instances. So pickle.loads should never be used on untrusted strings, except possibly in a rexec wrapper (as proposed by Tim). Another possibility (also by Tim) is to override the load_inst method of the Pickler class, though I don't think you can do that for cPickle. A sample exploit for unpickle can be found at . Unpickling the test string runs penguin.__init__ contrary to the doc's saying no initialization unless there's a __getinitargs__ method in the class def. The "exploding penguin" class is artificial, but applications are vulnerable if there's an unsafe constructor anywhere in any class of the application or in the python library (example: the NNTP constructor opens an IP connection to an arbitrary address, so a malicious imported string can send a message through your firewall when you import it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471893&group_id=5470 From noreply@sourceforge.net Tue May 13 20:02:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 12:02:07 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-692881 ] import files from any directory Message-ID: Feature Requests item #692881, was opened at 2003-02-25 15:37 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=692881&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: import files from any directory Initial Comment: Many times I have a .py file with some functions, which I want to import. However, its functionality is very specific, so I don't want to copy it to a directory where it will always be available as a module. If I start Python from the directory of the file, I can import it, but this is not always the case. I can use execfile(), but import is better since it runs the file in its own namespace. What I suggest is to extend the import statement syntax, to allow "module" to be a stringliteral as well as (identifier ".")* identifier. When it is a string literal, the string will be interpreted as the file name to import. The default name of the module will be the name which would import the file if its directory were in PYTHONPATH. If there is no such name, an exception will be raised if "as" is not used. For example, say the file with my functions is called "specific_functions.py" and sits in the directory "/dir". When I open the Python shell from the directory /dir, I can now call "import specific_functions". I suggest that this would do the same thing: "import 'specific_functions.py' ". When I open the Python shell from another directory, I currently have no simple way to import the file, but I suggest that I could use the command "import '/dir/specific_functions.py' ". The command "from '/dir/specific_functions.py' import *" should also work, of course. This has no backward compatibility issues as far as I can see, and is quite helpful, I think. ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2003-05-13 22:02 Message: Logged In: YES user_id=679426 I don't agree with alexanro, but I do think that adding the directory to sys.path is a pretty good solution. cool! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 06:58 Message: Logged In: YES user_id=357491 You can add the directory to sys.path and then do a normal import. ---------------------------------------------------------------------- Comment By: Alexander Rødseth (alexanro) Date: 2003-05-12 17:50 Message: Logged In: YES user_id=679374 Today, chances are quite good that a random downloaded python-script will function on any computer. This suggestion would increase the chances that one will get errors connected to "missing files" (from 0% to some%, which is a great deal). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=692881&group_id=5470 From noreply@sourceforge.net Tue May 13 20:03:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 12:03:55 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-453506 ] lists should have a copy method Message-ID: Feature Requests item #453506, was opened at 2001-08-20 17:23 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Rejected Priority: 1 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: lists should have a copy method Initial Comment: This is per someone on comp.os.python. It's odd that dictionaries have a copy method (you can say dict.copy()) but to copy a list you have to say list[:] or use copy.copy. I think list.copy() should be added for consistency. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-13 15:03 Message: Logged In: YES user_id=31435 In this context, schmuitive means Guido isn't going to add list.copy(), and doesn't think more argument about it is a good use of his time. Surely that was obvious ? ---------------------------------------------------------------------- Comment By: Jesper Hertel (jhmagnus) Date: 2003-05-13 10:01 Message: Logged In: YES user_id=592328 What does schmuitive mean? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-13 09:34 Message: Logged In: YES user_id=6380 Intuitive, schmuitive. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 21:57 Message: Logged In: YES user_id=31435 Assigned to Guido for rejection . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:46 Message: Logged In: YES user_id=357491 I'm with Tim; you don't need seven ways to copy (Tim forgot using a list comprehension and ``map(None, list)`` =). I say this RFE gets rejected. ---------------------------------------------------------------------- Comment By: Jesper Hertel (jhmagnus) Date: 2003-01-21 09:30 Message: Logged In: YES user_id=592328 I agree that it would be nice (and consistent) if lists had a copy() method. It would be more convenient. It is always tiresome to have to import modules to do simple stuff like this. The list[:] is a trick that you have to know before you can use it (it doesn't seem obvious to me), but list.copy() seems intuitive to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-23 01:43 Message: Logged In: YES user_id=31435 I doubt Guido would go for it. dicts grew a .copy() method *because* there was no convenient syntax like list[:] that worked for dicts. That's not a reason to add a .copy() method to lists too. Note that if you're too fond of uniformity , don't use any of these: use copy.copy() or copy.deepcopy(). Python doesn't need four ways to spell "copy this list". Oops: make that five. list (somelist) also copies a list. In 2.2, dict(somedict) also copies a dict. Enough already. ---------------------------------------------------------------------- Comment By: Michael Gilfix (mgilfix) Date: 2002-04-22 23:53 Message: Logged In: YES user_id=116038 What's the status of this? It seems pretty useful. I could submit a patch if someone likes... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 From noreply@sourceforge.net Tue May 13 20:31:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 12:31:38 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-447143 ] exception item from mapped function Message-ID: Feature Requests item #447143, was opened at 2001-08-02 04:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: exception item from mapped function Initial Comment: The purpose of this enhancement would be to get the item in a list that caused an exception when applying a mapped function. For instance, suppose that I want to detect if there is an item in a list that is not a number. For this illustration I try to map float on the list and then catch the exception. try: map(float, mylist) except ValueError: print "The item %s in mylist is not a number." % (my_item) The problem is that I do not know which item in the list caused the exception. How do I get my_item? This information could probably be useful in a number of different contexts. Thank you. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-13 12:31 Message: Logged In: YES user_id=357491 Considering it will probably require changing the binary layout of exceptions I would have to agree that a PEP is in order. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-13 00:21 Message: Logged In: YES user_id=89016 I'm still planning to give this a try someday, but maybe this should be part of the big "new style exceptions PEP"? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 00:04 Message: Logged In: YES user_id=357491 True. I remember this being discussed at one point and people thinking it was a good idea but it never got implemented. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-13 00:01 Message: Logged In: YES user_id=89016 I we had exception chaining (i.e. each exception can reference another exception, that is the cause for this one), this would just be a special case. A traceback could then look like this: >>> map(float, [0, 1, None, 3]) Traceback (most recent call last): File "", line 1, in ? TypeError: in entry None at position 2 Caused by: TypeError: float() argument must be a string or a number ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:59 Message: Logged In: YES user_id=357491 Well, if you were doing this with a list comprehension it isn't hard:: try: float_list = [float(x) for x in mylist] except ValueError: print "The item %s in mylist is not a number." % x Since list comprehensions are practically just a 'for' loop in a much tighter way the variables used stick around just as if you had used a 'for' loop. The other issue is the way errors propogate in C. If map were to return its own error specifying which item caused a problem it would have to overwrite the exception that was raised in the first place and overwriting exceptions on the whole is bad. If you really are in love with map you can always define your own wrapper around float to raise the exception you want:: def myfloat(num): try: return float(num) except ValueError: raise ValueError("The item %s in mylist is not a number." % num) I personally feel this RFE should be rejected. Anyone else agree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=447143&group_id=5470 From noreply@sourceforge.net Tue May 13 21:53:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 13:53:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-737291 ] os.symlink docstring is ambiguous. Message-ID: Bugs item #737291, was opened at 2003-05-13 16:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: os.symlink docstring is ambiguous. Initial Comment: >>> print os.symlink.__doc__ symlink(src, dst) Create a symbolic link. I find that to be ambiguous -- personally, when I read it, I picture the symlink as the source pointing to the destination, but apparently Python considers the symlink to be the "destination" file pointing at the source (the file). I propose simply changing "src" in the docstring to be "filename" and "dst" in the docstring to be "linkname." That would cut out the ambiguity. (It's unfortunate, btw, that os.symlink takes its arguments in the opposite order of the UNIX ln command.) Jeremy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737291&group_id=5470 From noreply@sourceforge.net Tue May 13 22:13:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 14:13:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-737291 ] os.symlink docstring is ambiguous. Message-ID: Bugs item #737291, was opened at 2003-05-13 16:53 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: os.symlink docstring is ambiguous. Initial Comment: >>> print os.symlink.__doc__ symlink(src, dst) Create a symbolic link. I find that to be ambiguous -- personally, when I read it, I picture the symlink as the source pointing to the destination, but apparently Python considers the symlink to be the "destination" file pointing at the source (the file). I propose simply changing "src" in the docstring to be "filename" and "dst" in the docstring to be "linkname." That would cut out the ambiguity. (It's unfortunate, btw, that os.symlink takes its arguments in the opposite order of the UNIX ln command.) Jeremy ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-05-13 17:13 Message: Logged In: YES user_id=99508 (ignore that last comment...brain fart...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737291&group_id=5470 From noreply@sourceforge.net Tue May 13 23:35:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 15:35:08 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-449187 ] if x in 1,2,3: should work Message-ID: Feature Requests item #449187, was opened at 2001-08-08 12:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) >Assigned to: Guido van Rossum (gvanrossum) Summary: if x in 1,2,3: should work Initial Comment: There is normally some symmetry between 'for x in whatever' and 'if x in whatever'. However, the symmetry is broken (for syntax reasons I do not understand) in one case, a tuple-without-parentheses: for x in 1, 2, 3: pass works fine, but if x in 1, 2, 3: pass gives a syntax error. Can the syntax error be removed? I think it violates the principle of least astonishment, as one would expect that either both forms would work or neither would. (I'd offer a patch, but I don't think I really understand the way Python syntax is implemented in the Python compiler...!-). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-13 18:35 Message: Logged In: YES user_id=31435 We should close it, or not . Whether the for- statement decides to use test or testlist is really independent of what other statements decide to do. The if-statement *could* have decided to use testlist too, but because of examples given before it would have been surprising if it had. Ditto for the while-statement. Assigning to Guido for final disposition. I don't think this could be changed before Python 3 regardless. I remember being confused about this when I first used Python too. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 01:34 Message: Logged In: YES user_id=357491 Nuts. Oh well. Then should we close this RFE? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-13 00:04 Message: Logged In: YES user_id=80475 No dice, then non-parenthesis version occurs throughout Python (blame the comma, not the parens): t = 'a', 'b', 'c' # This works. return 'a', 'b', 'c' # So does this. for letter in 'a', 'b', 'c': So this should also. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:53 Message: Logged In: YES user_id=357491 That's why I want for to be changed so that it needs parentheses. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 21:38 Message: Logged In: YES user_id=31435 The fundamental problem is that, as an expression, "x in 1, 2, 3" doesn't group as an if-statement would need it to group: >>> y = 'a' in 'a', 'b', 'c' >>> y (True, 'b', 'c') >>> >>> for y in 'a' in 'a', 'b', 'c': ... print y ... True b c >>> So if Python did allow a testlist as the 'if' expression, it would be parsed as: if ((x in 1), 2, 3): which is a surprising way of raising TypeError. The parens are really needed to get the 1, 2, 3 part parsed as a tuple. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:11 Message: Logged In: YES user_id=357491 I didn't know Python accepted that 'for' structure!?! I agree with Alex that this should be changed at some point. As for why this is, it appears that the offending grammar definitions are: for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] testlist: test (',' test)* [','] test: and_test ('or' and_test)* | lambdef So it looks like the difference is 'for' uses testlist while 'if' uses just test. Probably can just swap out testlist for test and get the result you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 From noreply@sourceforge.net Wed May 14 11:47:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 03:47:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-722413 ] _winreg doesn't handle NULL bytes in value names Message-ID: Bugs item #722413, was opened at 2003-04-16 20:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722413&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: _winreg doesn't handle NULL bytes in value names Initial Comment: Reported via pywin32 mailing list >>We are trying to read all of the data under specific registry keys. >>Unfortunately, we cannot seem to enumerate keys or values >>correctly if >>the name contains Unicode or binary characters. >> >> > >Eeek - you mean the *value* names can contain embedded NULL characters?! > > The value names can contain NULL bytes. The NT/2K/XP registry is all MBCS. The value names cannot contain MBCS character 0. The key names ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-05-14 20:47 Message: Logged In: YES user_id=14198 Dupe of 672132 - and I submitted them both! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-29 05:33 Message: Logged In: YES user_id=31435 Reassigned to MarkH. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722413&group_id=5470 From noreply@sourceforge.net Wed May 14 13:12:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 05:12:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-737648 ] Error on handling nan Message-ID: Bugs item #737648, was opened at 2003-05-14 12: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=737648&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Seiwald (bseiwald) Assigned to: Nobody/Anonymous (nobody) Summary: Error on handling nan Initial Comment: We found some strange behavior of the handling of "nan" if "nan" is used in if-statements. We use Python 2.2 (python2-2.2.2-11.7.3.src.rpm). In the following i show the results of the "experiments" with "nan", "inf" and usual floats: $ python Python 2.2.2 (#1, Jan 30 2003, 21:26:22) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=float(1.2345) >>> b=float("inf") >>> c=float("nan") >>> if a==b: ... print "equal" ... >>> if a==c: ... print "equal" ... equal >>> if b==c: ... print "equal" ... equal Bernhard Seiwald seiwald@itp.tugraz.at ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737648&group_id=5470 From noreply@sourceforge.net Wed May 14 16:59:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 08:59:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-734806 ] telnetlib.read_until: float req'd for timeout Message-ID: Bugs item #734806, was opened at 2003-05-08 14:27 Message generated for change (Comment added) made by cba037 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734806&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Craig Allen (cba037) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.read_until: float req'd for timeout Initial Comment: The read_until (and I assume expect) method(s) have an optional timeout parameter; a float is required but this is not documented; use of an integer causes an exception. Documentation needs to mention the need for a float value (alternatively, telnetlib should convert to a float). ---------------------------------------------------------------------- >Comment By: Craig Allen (cba037) Date: 2003-05-14 11:59 Message: Logged In: YES user_id=84913 The exception, which my program catches, was 'a float is required'. No traceback was provided. I have been unable to reproduce this error in a test program. It is worth noting that subsequent to reporting this "bug", I have upgraded from 2.3a1 to 2.3b. It looked to me that the timeout argument is passed to select.select, which apparently expects a float, yet an integer does not seem to cause an exception. Since we don't seem to be able to reproduce the error, I think we could close this bug. Do I need to do that? Craig Allen ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:20 Message: Logged In: YES user_id=11375 I can't replicate this; an integer value seems to work fine for me. Can you provide a test program that manifests the problem? And what exception and traceback do you get? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734806&group_id=5470 From noreply@sourceforge.net Wed May 14 17:22:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 09:22:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-737734 ] need doc for new trace module Message-ID: Bugs item #737734, was opened at 2003-05-14 16: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=737734&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: need doc for new trace module Initial Comment: see summary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737734&group_id=5470 From noreply@sourceforge.net Wed May 14 17:47:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 09:47:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-734806 ] telnetlib.read_until: float req'd for timeout Message-ID: Bugs item #734806, was opened at 2003-05-08 14:27 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734806&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Craig Allen (cba037) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.read_until: float req'd for timeout Initial Comment: The read_until (and I assume expect) method(s) have an optional timeout parameter; a float is required but this is not documented; use of an integer causes an exception. Documentation needs to mention the need for a float value (alternatively, telnetlib should convert to a float). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-14 12:47 Message: Logged In: YES user_id=11375 I seem to recall that there were some changes related to PyArg_ParseTuple's format codes during the alpha cycle; perhaps they caused your problem and have since gotten fixed. I'll close the bug. (Unless you're granted admin privileges on the Python SourceForge project, you can't close it.) ---------------------------------------------------------------------- Comment By: Craig Allen (cba037) Date: 2003-05-14 11:59 Message: Logged In: YES user_id=84913 The exception, which my program catches, was 'a float is required'. No traceback was provided. I have been unable to reproduce this error in a test program. It is worth noting that subsequent to reporting this "bug", I have upgraded from 2.3a1 to 2.3b. It looked to me that the timeout argument is passed to select.select, which apparently expects a float, yet an integer does not seem to cause an exception. Since we don't seem to be able to reproduce the error, I think we could close this bug. Do I need to do that? Craig Allen ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 10:20 Message: Logged In: YES user_id=11375 I can't replicate this; an integer value seems to work fine for me. Can you provide a test program that manifests the problem? And what exception and traceback do you get? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734806&group_id=5470 From noreply@sourceforge.net Wed May 14 17:52:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 09:52:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-471893 ] Security review of pickle/marshal docs Message-ID: Bugs item #471893, was opened at 2001-10-16 18:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471893&group_id=5470 Category: Extension Modules Group: None >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: Security review of pickle/marshal docs Initial Comment: Paul Rubin points out that the security implications of using marshal and/or pickle aren't clear from the docs. Assigning to Jeremy as he's more sensitive to such issues than I am; maybe Barry would like to get paranoid too . A specific example: the pickle docs say that pickle doesn't support code objects, and "at least this avoids the possibility of smuggling Trojan horses into a program". However, 1) The marshal docs don't mention this vulnerability at all. while 2) The pickle docs don't spell out possible dangers due to things pickle does that marshal doesn't (like importing modules, and running class constructors). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-14 12:52 Message: Logged In: YES user_id=11375 Checked in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-13 14:48 Message: Logged In: YES user_id=31435 Yes, please do! And thank you. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 09:34 Message: Logged In: YES user_id=11375 Can I check this in? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-26 14:22 Message: Logged In: YES user_id=11375 OK; here's a reworked version that retitles the "Pickle security" section to "Subclassing Unpicklers", leaving the discussion of subclassing alone except for a few typo fixes. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-06 14:40 Message: Logged In: YES user_id=31435 I think there are several reasons to override these methods. The one most relevant to this bug report is that, while Python has stopped pretending that pickles are secure by default, the choke points are still there, and motivated users can still expolit them. For example, search pickle.py for __import__. The only occurrence of __import__ in the Unpickler class is in method find_class(), and that's by design. If a user overrides find_class(), the only imports the Unpickler *can* do are those the user explicitly performs in their own find_class() implementation. So if that's a notion of "security" a user is happy with, they can still have it. The docs trying to describe this are still valid. It's only the "by magic" safety checks that have gone away (and they were buggy anyway, so no loss). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-06 09:29 Message: Logged In: YES user_id=11375 The Cookie classes that use pickle have DeprecationWarnings in 2.3, and should disappear in 2.4. If {find,load}_global are still going to be supported, though, then they should still be documented (though, given that you shouldn't be unpickling untrusted data, why would you ever bother overriding find_global?) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-02-05 18:03 Message: Logged In: YES user_id=12800 I'll just mention that anybody using anything other than Cookie.SimpleCookie is insane, and even using the Cookie module at all to parse real-world cookies is mildly nuts because it's way too strict. I prefer m&m's in my cookies. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-05 17:57 Message: Logged In: YES user_id=31435 Andrew, didn't you go overboard in deleting text here? The __safe_for_unpickling__ check is gone in 2.3, but most of the rest of the text still applies. In particular, Cookie is still a problem for people inclined to worry about this, and overriding methods like find_global and load_global is still valuable stuff (the unpickler still never imports anything that doesn't come from an opcode triggering one of these methods). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-02-05 16:29 Message: Logged In: YES user_id=12800 Karmically (no, not comically) reassigning to Tim who started this whole thing, and who happens to be dumping his pickles these days. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-05 15:40 Message: Logged In: YES user_id=11375 Re-opening. With the changes to pickling in Python 2.3, the security material should be replaced with a warning to not unpickle untrusted data. Patch attached. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-18 11:08 Message: Logged In: YES user_id=12800 You're right of course. I meant to fix that and forgot. Will do so asap. Glad you like the rest of it, though! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-18 01:56 Message: Logged In: NO Barry - the new docs just went up and they're a big improvement over the old. However the sentence "The issue here is usually not that a class's constructor will get called -- it won't by the unpickler -- but that the class's destructor (i.e. its __del__() method) might get called when the object is garbage collected." isn't correct. There's a flag in the pickle stream that tells the unpickler that the pickler found a __getinitargs__ method at pickling time. If the flag is set in the pickle, then the unpickler calls the class constructor, whether there's a __getinitargs__ method in the class or not. The sample exploit that I posted earlier on, , is an example of an artificially concocted pickle that makes a class constructor get called. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-17 17:07 Message: Logged In: NO Are the new docs downloadable from somewhere? thanx --Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-15 19:43 Message: Logged In: NO Barry, can you also do something about the Cookie module, or at least about its documentation? If Cookie is aliased to SmartCookie, I think that needs mention. --Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-15 19:12 Message: Logged In: YES user_id=12800 I have rewritten the pickle documentation, and updated the marshal, cPickle, and copy_reg documentation. I believe all the documentation issues raised here have been fixed. Implementation issues will be pushed to Python 2.3, and the plan is to write a PEP to plan future work. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-13 16:39 Message: Logged In: YES user_id=12800 Assigning to Jeremy so he'll remember to forward me Jim's email. Jeremy can ping-pong it to Fred if he wants, and then reassign to me after forwarding the email. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-13 01:18 Message: Logged In: NO The find_global variable sounds encouraging and if it fixes this problem, that's great. I'd still feel better if the eval call goes away. Is removing it allowed under the 2.2 feature freeze? It doesn't affect anything visible, so no tests would have to change, etc. Paul ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 19:38 Message: Logged In: NO It's possible that the eval is safe, but validating that takes a line by line code review of all the paths that evaling a string can go through. It's also brittle in that maybe someone will change the evaluator (say to support Perl-like interpolation) in a future Python version and not remember to change the unpickler. Something like that has already happened with the Cookie module. My guess is that it happened with the pickle module--the whole point of that quoted string check is that the original pickle implementer didn't trust the input. The stuff about unpickling class instances was added later (maybe by another person) without remembering the security issue. Using eval this way is like storing a vat of cyanide in your child's bedroom. Sure, maybe if you check the seals and locks on the vat carefully enough, you can convince yourself that your child won't be able to get to the cyanide. But wouldn't you feel safer just not having the vat there at all? That's basic safety-consciousness. Security consciousness works the same way. Try to keep dangerous ingredients and attackers as far away from each other as possible. Paul ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-12 13:52 Message: Logged In: YES user_id=31435 Why are people (Paul, Jeremy) concerned about eval'ing strings? cPickle and pickle both check that they're properly quoted, and this isn't sh or Perl: Python has no "dynamic" gimmicks buried in string literals. All eval'ing a string literal can do is produce a binary blob via interpeting simple escape sequences. They're like C strings this way -- maybe we'll run out of memory, but that's it. I would agree that Python should be refactored internally to supply a clean function for changing string literals into binary blobs, but that would be for clarity and efficiency, not security. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2001-11-12 13:14 Message: Logged In: YES user_id=73023 It sounds like there are some documentation bugs: - The security ramifications are not discussed, nor are the remedies. - The cPickle module isn't documented very well. I submitted some documentation a long time ago that never got incorporated AFAIK. I wish I still had it. :) - cPickle has a feature for turning off instance support and for restricting which classes can be unpickled. You can set the find_global attribute on a cPickle.Unpickler. The find_global attribute can be a function or None. If it is None, then no instances can be unpickled. If it is a function, then it should accept a module and name and return the corresponding global. It is responsible for looking up the global and can raise an error to prevent a global's use. See the ZEO storage server implementation for an example of using this hook. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 01:33 Message: Logged In: NO I like marshal and think it's much cleaner than pickle. I'd like to see its format cleaned up and documented so it can be a portable transport format. Even the recursion issue isn't so compelling--there's only a danger on marshalling, not unmarshalling, and the application has control over what it marshals. So I think the idea of documenting marshal (bug #467384) should be kept alive. However, it shouldn't be changed in 2.2. If the Cookie class is still really aliased by default to SmartCookie, that's a bad bug and should definitely be fixed ASAP. The Cookie docs clearly say not to use SmartCookie or SerialCookie. In fact I think SmartCookie and SerialCookie should be disabled altogether. Any applications using them on the open internet have a security but and should be fixed immediately. Here's a possible temporary approach to fixing SmartCookie and SerialCookie: append a cryptographic message authentication code (MAC) to each pickled cookie. That means the application has some secret string K as a configuration parameter (it should be 10 or more random 8-bit characters, or 20 or more random hex digits, etc). Then a smart cookie would be a pickle p, followed by SHA(p+K). The Cookie module would validate the MAC before calling unpickle, and raise an exception if the MAC wasn't valid. The security of this scheme rests on K being kept secret from attackers, which is generally not an easy thing to manage, but it's something to think about. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-10 17:07 Message: Logged In: YES user_id=31392 I don't think we should be doing anything about marshal. Maybe we should name in pyclib or something <0.9 wink>. It works fine for .pyc files, but I don't see a reason for it to do anymore than is necessary for that purpose. I think the notion of an unpickler that only handles builtin datatypes is the most attractive option you offer, but Paul has a good point about eval for strings. (It currently has some hacks that address specific exploits, but I doubt they are sufficient.) I also wonder how hard it is to handle builtin types and avoid subclasses of builtin types. If there are any changes to pickle, I think we need to be careful about how it is described. If we claim that an unpickler is safe for untrusted pickles, we've made a fairly strong claim. I still think such a design change requires a PEP that includes some requirements and use cases and a thorough analysis of potential exploits. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-10 14:42 Message: Logged In: NO See bug #467384 for discussion about marshal. Besides the recursion issue, marshal's format is explicitly undocumented and subject to change--you can't rely on it to interoperate between two different Python versions, so it's no good as an RPC serializer. The format has kludges (e.g. the representation of long ints) that make it undesirable to freeze and document it and force future versions to be backward compatible. Adding a pickle.loads flag to prevent instance unpickling isn't perfect but is probably the best alternative on your list. Perhaps the flag can have a value that allows unpickling the instances by restoring the instance attributes rather than calling the initializer. That's not always the right way to unpickle an instance (that's why the unpickler no longer works that way) but it's good enough a lot of the time. There's another issue with pickle/cPickle which is that they unpickle quoted strings by evaling them. This is scary. While I don't see an immediate exploit, I also haven't examined the 1000's of lines of code I'd need to examine to convince myself that there's NOT an exploit. I think the unpickler should be changed to never call eval but just parse the string as it needs to. Guido seemed to think pickle might have other possible exploits. I don't know what he had in mind but before declaring it safe for untrusted data I think it needs to be gone over with a fine toothed comb. Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-11-10 12:37 Message: Logged In: YES user_id=12800 I'm going to agree with Paul that this is a problem needing fixing, however there are really several issues. 1. Cookie module makes it too easy to code exploits. Cookie exports a class, also called Cookie, which is aliased to SmartCookie, so that a naive program will simply pass cookie data to Cookie.Cookie() and you're screwed. So, Cookie module's defaults should be for more security rather than less, and Cookie.Cookie should be aliased to SimpleCookie instead. 2. There is no built-in safe mechanism for de-serializing data from untrusted sources. You can't use pickle without overloading a "magic" method. You can't use cPickle because you can't do the overloading trick. You can't use marshal because it isn't bulletproof against recursive datastructures. So how /do/ you do it? I think it just may be serious enough to deal with in Python 2.2, and I volunteer to address it (so I'll steal this bug report). Without looking at the code, or the level of effort necessary, I would make the following suggestions: 1. Add to the public interface of pickle and cPickle, a flag that either disables the unpickling of instances altogether, or disables calling any code with unpickled data, e.g. constructors. 2. Fix marshal to be bulletproof against recursive datastructures. 3. Update the docs for both pickle/cPickle and marshal to explain how to safely write de-serializers of untrusted strings. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-09 04:21 Message: Logged In: NO Well, Guido and Tim agree with you that it's not a pickle bug. I still feel it is one, because its docs currently make you think you can securely load untrusted pickles, and because it's a natural, non-obscure thing to want to do (see pyro and the cookie module), but whatever. If it's not a code bug then I feel it's a significant functionality shortcoming in the python library. Pyro uses pickle to serialize data for RPC calls over the internet. A malicious client could make a hostile pickle take over the server. The cookie module lets web applications store user session state in browser cookies. Its SerialCookie and SmartCookie classes let you put arbitrary Python objects into the user session, and serializes them when pickle. Again, a malicious client can make a hostile pickle, send it in a cookie header to the http server, and take over the server when the application unpickles the cookie. The current documentation for the pickle module makes it very clear to me that the doc writer thought it was safe to unpickle untrusted cookies. If pickle wasn't designed for that, then there was a communication failure between the designer and the doc writer. Yes, I'm willing to help with a PEP for fixing this situation. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-08 12:37 Message: Logged In: YES user_id=31392 I don't think of the issue you describe as a bug in the code. You're suggesting a new feature for pickle. As far as I can tell, the original design requirements for pickle did not include the ability to securely load a pickle from an untrusted source. It may be a legitimate feature request, but it's too late to make it into Python 2.2. I suggest we look at the design issues for Python 2.3 and decide if it's a feature we want to support. I imagine a PEP may be necessary to lay out the issues and the solution. Do you want to have a hand in that PEP? I still don't understand what it means that Pyro and cookie were bit by a bug. It sounds like they were using pickle in ways that pickle was not intended to support. A careful analysis of how those two applications use pickle would be helpful for generating requirements. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-07 18:54 Message: Logged In: NO IMO it's a code bug that you can't unpickle strings from untrusted sources. Pyro and the cookie module are examples of programs that got bitten by this bug. Whether it's really a bug is a matter of opinion--I had a big email exchange with Guido and Tim about it, and they felt it was enough to fix the pickle documentation. Pickle has the same problem as cPickle, but with pickle you can subclass the pickler and override the method that unpickles class objects, and work around the (IMO) bug. The workaround doesn't help cPickle since cPickle can't be subclassed. See bug #467384 for some related discussion. Paul ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-07 17:02 Message: Logged In: YES user_id=31392 What's the code bug? Your last message has a lot of gloom and doom , but I'm not sure what specific problem you'd like to see fixed. Are you saying that something needs to be fixed in cPickle and not in pickle? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-07 15:08 Message: Logged In: NO Irmen de Jong points out that the standard cookie module uses pickling for serial and smart cookies. The 2.1.1 cookie module docs explicitly say not to use those classes because of the security hole--that they're provided for backward compatibility only (but with what?! Any server that uses those classes on open ports needs to be changed right away). Irmen's library, http://pyro.sourceforge.net, also uses unpickle insecurely (he's aware of this now and is figuring out a fix). IMO this is really a code bug rather than a documentation bug, and should be fixed in the code rather than the docs. Documenting the bug rather than fixing it leaves a deficiency in the Python library: obvious uses of pickling, like Pyro and the cookie module, can't be implemented using cPickle and have to resort to a slower Python deserializer, or use marshal and have possible compatibility problems between versions (and not be able to serialize class instances). Paul ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-16 19:06 Message: Logged In: YES user_id=72053 Certainly anyone unserializing potentially malicious data with pickle, marshal, or anything else, should check the results before doing anything dangerous with them (like executing code). However, unpickle can potentially do damage before it even returns, by creating loading modules and creating initialized class instances. So pickle.loads should never be used on untrusted strings, except possibly in a rexec wrapper (as proposed by Tim). Another possibility (also by Tim) is to override the load_inst method of the Pickler class, though I don't think you can do that for cPickle. A sample exploit for unpickle can be found at . Unpickling the test string runs penguin.__init__ contrary to the doc's saying no initialization unless there's a __getinitargs__ method in the class def. The "exploding penguin" class is artificial, but applications are vulnerable if there's an unsafe constructor anywhere in any class of the application or in the python library (example: the NNTP constructor opens an IP connection to an arbitrary address, so a malicious imported string can send a message through your firewall when you import it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471893&group_id=5470 From noreply@sourceforge.net Wed May 14 18:12:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 10:12:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-732951 ] bsddb.*open mode should default to 'r' rather than 'c' Message-ID: Bugs item #732951, was opened at 2003-05-05 17:35 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732951&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: bsddb.*open mode should default to 'r' rather than 'c' Initial Comment: In module bsddb, the second argument of the open functions (e.g., btopen) should default to 'r' rather than 'c'. Most (all?) of the other open functions, both in the various dbm-like modules and for basic I/O default this way. If this change is not made, then at least this behavior should be documented clearly. Currently it's not documented at all (as far as I can find). Cheers, Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732951&group_id=5470 From noreply@sourceforge.net Wed May 14 23:51:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 15:51:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-737947 ] Failed assert in stringobject.c Message-ID: Bugs item #737947, was opened at 2003-05-14 22:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Failed assert in stringobject.c Initial Comment: Here's how to reproduce the problem: [~]> cat test.py import readline readline.get_completer_delims() [~]> echo 'execfile("test.py");print 10' | python python: Objects/stringobject.c:111: PyString_FromString: Assertion `str !=((void *)0)' failed. Abort This was tested with 2.2.1 under RedHat 8.0. On c.l.py, a Mandrake 9.0 (py2.2.2) user reported a segfault with the same. Martin reported not seeing the problem with 2.3b1. However, others suggested still filing it for a possible backport, and also in case the fix was accidental. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 From noreply@sourceforge.net Thu May 15 02:48:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 18:48:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-737648 ] Error on handling nan Message-ID: Bugs item #737648, was opened at 2003-05-14 08:12 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737648&group_id=5470 Category: Python Interpreter Core >Group: Feature Request >Status: Closed >Resolution: Later Priority: 5 Submitted By: Bernhard Seiwald (bseiwald) Assigned to: Nobody/Anonymous (nobody) Summary: Error on handling nan Initial Comment: We found some strange behavior of the handling of "nan" if "nan" is used in if-statements. We use Python 2.2 (python2-2.2.2-11.7.3.src.rpm). In the following i show the results of the "experiments" with "nan", "inf" and usual floats: $ python Python 2.2.2 (#1, Jan 30 2003, 21:26:22) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=float(1.2345) >>> b=float("inf") >>> c=float("nan") >>> if a==b: ... print "equal" ... >>> if a==c: ... print "equal" ... equal >>> if b==c: ... print "equal" ... equal Bernhard Seiwald seiwald@itp.tugraz.at ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-14 21:48 Message: Logged In: YES user_id=31435 Sorry, but all behavior in the presence of NaNs and infinities and signed zeroes is a platform- and release- dependent accident. Even that float("inf") didn't raise an exception for you is an accident (e.g., in Python 2.2.2 on Windows, it does raise an exception). I've added this to PEP 42's "non-accidental 754 support" feature request; you may also be interested in PEP 754 (support for 754 special values). Python has no 754 story now. If you want it to have one, consider volunteering work toward that end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737648&group_id=5470 From noreply@sourceforge.net Thu May 15 03:28:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 19:28:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-737947 ] Failed assert in stringobject.c Message-ID: Bugs item #737947, was opened at 2003-05-14 18:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Failed assert in stringobject.c Initial Comment: Here's how to reproduce the problem: [~]> cat test.py import readline readline.get_completer_delims() [~]> echo 'execfile("test.py");print 10' | python python: Objects/stringobject.c:111: PyString_FromString: Assertion `str !=((void *)0)' failed. Abort This was tested with 2.2.1 under RedHat 8.0. On c.l.py, a Mandrake 9.0 (py2.2.2) user reported a segfault with the same. Martin reported not seeing the problem with 2.3b1. However, others suggested still filing it for a possible backport, and also in case the fix was accidental. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-14 22:28 Message: Logged In: YES user_id=33168 revision 2.54 in Modules/readline.c fixed this problem. Patch #512981: Update readline input stream on sys.stdin/out change. The patch must be modified for 2.2.3 because there is an API change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 From noreply@sourceforge.net Thu May 15 06:52:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 22:52:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-738066 ] Interpreter crash: sigfpe on Alpha Message-ID: Bugs item #738066, was opened at 2003-05-15 07:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Jørgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter crash: sigfpe on Alpha Initial Comment: Multiplying two numbers makes the interpreter crash. The architecture is an Alpha running: Digital UNIX V4.0F (Rev. 1229); Sat Oct 26 16:44:55 MET DST 2002 Compaq Tru64 UNIX V4.0F (Rev. 1229); Thu Mar 23 08:45:31 MET 2000 Python 2.2.1 (#1, Jun 4 2002, 15:33:18) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.uname() ('OSF1', 'asrv', 'V4.0', '1229', 'alpha') >>> 1e300 * 1e300 Floating exception (core dumped) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 From noreply@sourceforge.net Thu May 15 08:00:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 00:00:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-738090 ] Section 13.3: htmllib.HTMLParser constructor definition amen Message-ID: Bugs item #738090, was opened at 2003-05-15 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738090&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: K. K. Woo (kkwoo) Assigned to: Nobody/Anonymous (nobody) Summary: Section 13.3: htmllib.HTMLParser constructor definition amen Initial Comment: Hi, In section 13.3, the htmllib.HTMLParser constructor description says: class HTMLParser(formatter) I was unable to understand that "formatter" mentioned above referred to something from section 12.1 ("formatter - generic output formatting"). Consequently, I didn't understand how to use the htmllib.HTMLParser base class until I searched on google, and found an example at http://www.tummy.com/python/Examples/showhrefs.txt (link valid as at 15-May-2003). May I suggest adding a cross-reference to section 12.1 in the "See Also: " section of 13.3? Regarding how to improve this section, I'm open to suggestion. Regards, Kevin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738090&group_id=5470 From noreply@sourceforge.net Thu May 15 10:32:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 02:32:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-736407 ] Problem With email.MIMEText Package Message-ID: Bugs item #736407, was opened at 2003-05-12 09:41 Message generated for change (Comment added) made by judasiscariot 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: Open 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: John Abel (judasiscariot) Date: 2003-05-15 09: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 15: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@sourceforge.net Thu May 15 10:53:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 02:53:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-738154 ] pdb doesn't find some source files Message-ID: Bugs item #738154, was opened at 2003-05-15 13:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738154&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: pdb doesn't find some source files Initial Comment: In python 2.2.2 code object attribute co_filename contains relative to sys.path path (in python 2.3 the path is absolute), so pdb doesn't find some source files (for example, in the site-packages directory). The attached patch extends functionality of the bdb.Bdb.canonic method up to searching source files in sys.path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738154&group_id=5470 From noreply@sourceforge.net Thu May 15 14:05:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 06:05:32 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-736470 ] An alternative to "range" Message-ID: Feature Requests item #736470, was opened at 2003-05-12 14:44 Message generated for change (Comment added) made by alexanro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736470&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Alexander Rødseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: An alternative to "range" Initial Comment: As far as I know, range() has often beeing critizised for beeing ugly, particualarly in connection with for-loops. In my eyes, it's also a bit inconsistent that range(x, y) creates a list from x to y, but not including y. My suggestion is to include a pascal-like way of creating lists, with ".." like this: l = [x..y] this would be equal to today's: l = range(x, y + 1) (which I think is quite ugly) Here's another example of how it would look: for i in [1..3]: print i Output: 1 2 3 This could be particularly useful for beginners, and is quite pythonic, as I see it. It's clear and consise, and would be a welcome addition to the python language. In connection with ie. string-manipulation, it would clear up things a great deal. ---------------------------------------------------------------------- >Comment By: Alexander Rødseth (alexanro) Date: 2003-05-15 13:05 Message: Logged In: YES user_id=679374 How about the math-like notation [1..2) then, in order to keep the half-open intervals? In my point of view, this would have much of the same clarifying effect. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 17:17 Message: Logged In: YES user_id=80475 A language should consistently use either half-open intervals or closed-intervals but *never* mix the two. The same applies to whether lists should be indexed starting at zero or one. Python consistently applies half-open intervals and zero based indexing; any contamination of these unifying themes would be a mistake. The alternatives each have their advantages. With closed intervals, you accurately highlight how easy it is to see the end-point. On the plus side for half-open intervals, it is easier to see how many elements are in the loop (e-b versus e-b+1) and it is easier to link successive intervals because of invariants like a[:n] + a[n:] = a[:]. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736470&group_id=5470 From noreply@sourceforge.net Thu May 15 14:11:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 06:11:33 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-736490 ] A way to iterate over several variables at once Message-ID: Feature Requests item #736490, was opened at 2003-05-12 15:14 Message generated for change (Comment added) made by alexanro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Alexander Rødseth (alexanro) Assigned to: Skip Montanaro (montanaro) Summary: A way to iterate over several variables at once Initial Comment: Okay. Here's the problem (which occurs frequently in graphics programming): I have, say, variables "red", "green" and "blue". Now I want to iterate "red" from 0 to 63, "green" from 10 to 127 and "blue" from 0 to 255 - all at the same time, and I really, really miss a nice way to do this in Python. Here's my suggestion for how this could be done, (in a better world): for red, green, blue in [0..63], [10..127], [0..255]: print red, green, blue (the ".." is taken from my previous suggestion, so that [0..63] simply means "range(0, 63 + 1)") My idea is that the above code would be translated to something like this (please notice the subtle elegancy of the two lines above, compared with the ones below...): red_list = range(0, 63 + 1) green_list = range(10, 127 + 1) blue_list = range(0, 255 + 1) longest = max(len(red_list), len(green_list), len(blue_list)) red_inc = (red_list[-1] - red_list[0]) / float(longest) green_inc = (green_list[-1] - green_list[0]) / float(longest) blue_inc = (blue_list[-1] - blue_list[0]) / float(longest) red = red_list[0] green = green_list[0] blue = blue_list[0] for count in range(longest): print int(red), int(green), int(blue) red += red_inc green += green_inc blue += blue_inc That's about it. :) (And yes, you could possibly rewrite the "long version" above, in an even cleaner and nicer manner, but still!) ---------------------------------------------------------------------- >Comment By: Alexander Rødseth (alexanro) Date: 2003-05-15 13:11 Message: Logged In: YES user_id=679374 After montanaro's comment, I agree that this might be too specific to add to Python. :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 17:23 Message: Logged In: YES user_id=80475 FYI, for your applications, Numeric may be very helpful. It has many tools for simulateously manipulation several vectors of the same length It includes functions like Matlab's linspace() and some non- linear variants that address your use case. With linspace() or an equivalent in hand, use zip() to loop over the vectors at the same time (lockstep iteration). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-12 16:33 Message: Logged In: YES user_id=44345 This is really very counterintuitive. At one point you say that [0..63] is the same as range(0, 63+1). By extension, [10..127] and [0..255] should also translate to relevant range() calls with step sizes of 1. However, that's not what your code does. You compute the longest sequence and then use that to divide the two shorter sequences into an equal number of steps. It seems you're simply asking for a straight line ramp from (0,10,0) to (63, 127, 255). Image manipulation programs I've used in the past have offered many other ways to proceed from one point in rgb space to another besides simple ramps, so while your desire is pretty common, it's hardly exhausts the reasonable ways to go from point A to point B. Why not write a generator function which takes starting and ending points and a step size, then returns each point in the ramp in turn, something like this only lightly tested code: def ramp(p1, p2, nsteps): "return nsteps points from p1 to p2" stepsize = ((p2[0]-p1[0])/float(nsteps), (p2[1]-p1[1])/float(nsteps), (p2[2]-p1[2])/float(nsteps)) for i in range(nsteps): yield (p1[0]+(stepsize[0]*i), p1[1]+(stepsize[1]*i), p1[2]+(stepsize[2]*i)) (Use range(nsteps+1) if you want to include the endpoint). You would then use it like so: for red, green, blue in ramp((0, 10, 0), (63, 127, 255), 128): print red, green, blue I think this request is too specific for adding to Python. ---------------------------------------------------------------------- Comment By: Alexander Rødseth (alexanro) Date: 2003-05-12 15:21 Message: Logged In: YES user_id=679374 One should possibly also include a way to specify the number of wanted steps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=736490&group_id=5470 From noreply@sourceforge.net Thu May 15 15:07:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 07:07:32 -0700 Subject: [Python-bugs-list] [ 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: Open 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-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@sourceforge.net Thu May 15 15:08:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 07:08:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-724621 ] email/quopriMIME.py exception on int (lstrip) Message-ID: Bugs item #724621, was opened at 2003-04-20 11:36 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Moshe Yudkowsky (myudkowsky) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/quopriMIME.py exception on int (lstrip) Initial Comment: Python 2.3a2+, Debian Summary: when I use the as_string() method on a multipart, multilevel message, I get an exception from email/quopriMIME.py, line 84, complaining about lstrip() of an integer. Initial condtions: I have a script that reads an email message, extracts some information, encapsulates the message and then forwards it with some commentary. This script works under Python 2.2.2. Failure: This script does not run under 2.3a2+ -- it fails on the as_string() method. In particular, at the file/lineno given above. Using the debugger, I see that in fact there *is* an integer at that point, the digit "1" to be exact. Looking up in the stack, I see that this function was called by the method _encode_chunks in Headers.py, and that the "newchunks" was [ (1, us-ascii ) ]. Please let me know if you need copies of the scripts, email messages, etc. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-15 10:08 Message: Logged In: YES user_id=12800 Yes, please upload (not paste) all relevant files needed for me to reproduce the problem. Please boil down your example as much as possible, but be sure to include a complete example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 From noreply@sourceforge.net Thu May 15 15:11:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 07:11:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-738066 ] Interpreter crash: sigfpe on Alpha Message-ID: Bugs item #738066, was opened at 2003-05-15 01:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Jørgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter crash: sigfpe on Alpha Initial Comment: Multiplying two numbers makes the interpreter crash. The architecture is an Alpha running: Digital UNIX V4.0F (Rev. 1229); Sat Oct 26 16:44:55 MET DST 2002 Compaq Tru64 UNIX V4.0F (Rev. 1229); Thu Mar 23 08:45:31 MET 2000 Python 2.2.1 (#1, Jun 4 2002, 15:33:18) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.uname() ('OSF1', 'asrv', 'V4.0', '1229', 'alpha') >>> 1e300 * 1e300 Floating exception (core dumped) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-15 10:11 Message: Logged In: YES user_id=33168 Is this still a problem with 2.2.2 or 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 From noreply@sourceforge.net Thu May 15 17:06:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 09:06:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-738361 ] crash error in glob.glob; windows + strange directories Message-ID: Bugs item #738361, was opened at 2003-05-15 12: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=738361&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: crash error in glob.glob; windows + strange directories Initial Comment: I'm attaching a zip file containing a python file and directory structure to test this. I ran into this bug in real life work, so, as contrived as the bug test may look, it happens. I was writing a function which recurses through directories and does stuff with the files it finds. glob.glob() doesn't return any files inside a directory named [_] glob.glob() crashes on a directory named [A--_B]. I tried a few different combinations of characters inside brackets, but this was the only one I could get it to crash on. the crash happens during the regular expression compilation, as probably can be surmised by seeing the characters which cause it ( [] ). it also may be a combination of that and using \ as the directory delimiter since this is win32. File "C:\temp\globbug\bug.py", line 5, in test fs = glob.glob( path + '\*' ) File "C:\Python22\lib\glob.py", line 24, in glob list = glob(dirname) File "C:\Python22\lib\glob.py", line 37, in glob sublist = glob1(dirname, basename) File "C:\Python22\lib\glob.py", line 50, in glob1 return fnmatch.filter(names,pattern) File "C:\Python22\lib\fnmatch.py", line 47, in filter _cache[pat] = re.compile(res) File "C:\Python22\lib\sre.py", line 179, in compile return _compile(pattern, flags) File "C:\Python22\lib\sre.py", line 229, in _compile raise error, v # invalid expression sre_constants.error: bad character range ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 From noreply@sourceforge.net Thu May 15 19:31:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 11:31:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-738066 ] Interpreter crash: sigfpe on Alpha Message-ID: Bugs item #738066, was opened at 2003-05-15 01:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Jørgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter crash: sigfpe on Alpha Initial Comment: Multiplying two numbers makes the interpreter crash. The architecture is an Alpha running: Digital UNIX V4.0F (Rev. 1229); Sat Oct 26 16:44:55 MET DST 2002 Compaq Tru64 UNIX V4.0F (Rev. 1229); Thu Mar 23 08:45:31 MET 2000 Python 2.2.1 (#1, Jun 4 2002, 15:33:18) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.uname() ('OSF1', 'asrv', 'V4.0', '1229', 'alpha') >>> 1e300 * 1e300 Floating exception (core dumped) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-15 14:31 Message: Logged In: YES user_id=31435 Python inherits its floating-point behavior from whatever your C compiler and libraries happen to do. So, presumably a plain C program would do the same thing with this example. If that's not what you want, your C compiler probably supports some option to compile code that acts more the way you want it to work, and then you should compile Python with that option too. IIRC (I've never run on an Alpha), by default Alphas don't have compliant IEEE-754 fp arithmetic, and by default C compilers on Alphas don't try to repair that. If the compiler you're using as an option named "-ieee", try it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-15 10:11 Message: Logged In: YES user_id=33168 Is this still a problem with 2.2.2 or 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 From noreply@sourceforge.net Thu May 15 21:16:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 13:16:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-738471 ] csv.Sniffer docs need updating Message-ID: Bugs item #738471, was opened at 2003-05-15 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738471&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: csv.Sniffer docs need updating Initial Comment: The csv.Sniffer docs need to catch up with the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738471&group_id=5470 From noreply@sourceforge.net Fri May 16 01:34:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 17:34:25 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-449187 ] if x in 1,2,3: should work Message-ID: Feature Requests item #449187, was opened at 2001-08-08 12:07 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Guido van Rossum (gvanrossum) Summary: if x in 1,2,3: should work Initial Comment: There is normally some symmetry between 'for x in whatever' and 'if x in whatever'. However, the symmetry is broken (for syntax reasons I do not understand) in one case, a tuple-without-parentheses: for x in 1, 2, 3: pass works fine, but if x in 1, 2, 3: pass gives a syntax error. Can the syntax error be removed? I think it violates the principle of least astonishment, as one would expect that either both forms would work or neither would. (I'd offer a patch, but I don't think I really understand the way Python syntax is implemented in the Python compiler...!-). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-15 20:34 Message: Logged In: YES user_id=6380 I don't see the problem. You can always get what you want by adding parentheses. The parentheses can be left out when it's unambiguous. While it could be argued that if x in 1, 2, 3: ... is not ambiguous (after all the tuple ((x in 1), 2, 3) can never be false), it's not so simple in other contexts: a = x in 1, 2, 3 has a reasonable meaning. So I'm closing this with "won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-13 18:35 Message: Logged In: YES user_id=31435 We should close it, or not . Whether the for- statement decides to use test or testlist is really independent of what other statements decide to do. The if-statement *could* have decided to use testlist too, but because of examples given before it would have been surprising if it had. Ditto for the while-statement. Assigning to Guido for final disposition. I don't think this could be changed before Python 3 regardless. I remember being confused about this when I first used Python too. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 01:34 Message: Logged In: YES user_id=357491 Nuts. Oh well. Then should we close this RFE? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-13 00:04 Message: Logged In: YES user_id=80475 No dice, then non-parenthesis version occurs throughout Python (blame the comma, not the parens): t = 'a', 'b', 'c' # This works. return 'a', 'b', 'c' # So does this. for letter in 'a', 'b', 'c': So this should also. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:53 Message: Logged In: YES user_id=357491 That's why I want for to be changed so that it needs parentheses. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-12 21:38 Message: Logged In: YES user_id=31435 The fundamental problem is that, as an expression, "x in 1, 2, 3" doesn't group as an if-statement would need it to group: >>> y = 'a' in 'a', 'b', 'c' >>> y (True, 'b', 'c') >>> >>> for y in 'a' in 'a', 'b', 'c': ... print y ... True b c >>> So if Python did allow a testlist as the 'if' expression, it would be parsed as: if ((x in 1), 2, 3): which is a surprising way of raising TypeError. The parens are really needed to get the 1, 2, 3 part parsed as a tuple. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:11 Message: Logged In: YES user_id=357491 I didn't know Python accepted that 'for' structure!?! I agree with Alex that this should be changed at some point. As for why this is, it appears that the offending grammar definitions are: for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite] if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite] testlist: test (',' test)* [','] test: and_test ('or' and_test)* | lambdef So it looks like the difference is 'for' uses testlist while 'if' uses just test. Probably can just swap out testlist for test and get the result you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449187&group_id=5470 From noreply@sourceforge.net Fri May 16 02:32:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 18:32:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-735301 ] timeit.py doesn't see module globals Message-ID: Bugs item #735301, was opened at 2003-05-09 11:47 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: timeit.py doesn't see module globals Initial Comment: Simple test file (save as test.py) def test(): "Stupid test function" L = [] for i in range(100): L.append(i) if __name__=='__main__': from timeit import Timer t = Timer("test()") print t.timeit() Try to run this, and the following traceback occurs: >test.py Traceback (most recent call last): File "C:\Data\graph\test.py", line 10, in ? print t.timeit() File "C:\Apps\Python\lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "", line 6, in inner NameError: global name 'test' is not defined ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-15 21:32 Message: Logged In: YES user_id=6380 Yes, I know it's easy to provide the feature, but I'm against the feature. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2003-05-12 05:28 Message: Logged In: YES user_id=113328 If "Wont Fix" means just that, then that's OK. But for what it's worth, this change to timeit.py seems to do what I'd expect. --- timeit.py.orig 2003-05-12 10:23:55.000000000 +0100 +++ timeit.py 2003-05-12 10:24:06.000000000 +0100 @@ -115,7 +115,8 @@ self.src = src # Save for traceback display code = compile(src, dummy_src_name, "exec") ns = {} - exec code in globals(), ns + gbl = sys._getframe(1).f_globals + exec code in gbl, ns self.inner = ns["inner"] def print_exc(self, file=None): ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-05-09 14:22 Message: Logged In: YES user_id=44345 I added an example of this to the module documentation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 14:06 Message: Logged In: YES user_id=6380 You must import the test function from __main__ in the setup code fragment, e.g. t = Timer("test()", "from __main__ import test") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735301&group_id=5470 From noreply@sourceforge.net Fri May 16 02:42:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 18:42:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-735674 ] libwinsound.tex is missing MessageBeep() description Message-ID: Bugs item #735674, was opened at 2003-05-10 07:44 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: libwinsound.tex is missing MessageBeep() description Initial Comment: libwinsound.tex is missing a description of the MessageBeep() function. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-15 21:42 Message: Logged In: YES user_id=6380 LaTeX docs checked in. Case closed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 19:57 Message: Logged In: YES user_id=31435 FYI, the MB_xyz thingies work OK with MessageBeep () on my Win98SE desktop too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 19:03 Message: Logged In: YES user_id=31435 Hmm. OK. There's a disconnect here somewhere. Like why would you add a function to Python when you don't think it works correctly? I understand wanting to experiment on your own box. If it doesn't work, though, why add it to the distribution? FWIW, the 5 MB_xyz thingies work OK with MessageBeep () on my Win98SE laptop. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 16:40 Message: Logged In: YES user_id=6380 I really did mean what I wrote -- I wanted to experiment with different calls to MessageBeep() to see how far the damage extends. I tried the control panel and none of the sounds there are broken -- yet MessageBeep() is broken. We can look at this tomorrow in the office (my laptop is turned off right now and I have no time for experiments). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 12:03 Message: Logged In: YES user_id=31435 I don't think you meant what you wrote -- that you added MessageBeep() because MessageBeep() doesn't do what it's supposed to do. If PlaySound() gave a distorted click, and you're using it right, then you probably have a corrupt .wav file associated with the sound you tried to play; you can check that more directly via the Sounds applet in Control Panel (which lists the .wav file associated with sound names, and has a preview button to play them directly). About docs, did you read the Python docs for PlaySound ()? For example, MessageBeep(MB_ICONASTERISK) should do the same as PlaySound('SystemAsterisk', SND_ALIAS) The docs don't directly list MB_XYZ equivalents, but they're easy to guess from the Python docs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:21 Message: Logged In: YES user_id=6380 I added it because I discovered that on my Win98 machine certain calls to MessageBeep() make a funny sound (a very brief distorted click) rather than what they are supposed to do. I haven't found docs showing the resource names used by MessageBeep() that I could pass to SND_ALIAS. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:52 Message: Logged In: YES user_id=31435 Assigned to Guido because, IIRC, he added this function. Guido, why did you add it? It seems like a redundant way of calling winsound.PlaySound() with the SND_ALIAS argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735674&group_id=5470 From noreply@sourceforge.net Fri May 16 03:04:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 19:04:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-626926 ] Build error using make VPATH feature Message-ID: Bugs item #626926, was opened at 2002-10-22 11:36 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 Category: Build Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Davide Di Blasi (davidedb) Assigned to: Nobody/Anonymous (nobody) Summary: Build error using make VPATH feature Initial Comment: PROBLEM DESCRIPTION ===================== After building successfully Python 2.2.2 from scratch on Solaris 8 using the usual commands (cd ~wrk/Python-2.2.2; ./configure; make), I decided to build it for multiple architectures (SunOS 5.6, 5.7 and 5.8), exploiting the supported VPATH feature of GNU make. Here are the commands I run for Solaris 6: 1. mkdir ~/wrk/Python-2.2.2/binaries/SunOS_5.6 2. cd ~/wrk/Python-2.2.2/binaries/SunOS_5.6 3. ../../configure -prefix=/usr/local/python 4. make Unfortunately the last command failed with the following error:... ranlib libpython2.2.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.2.a -lsocket -lnsl -ldl -lpthread -lthread -lm case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py build;; \ esac running build running build_ext Traceback (most recent call last): File "../../setup.py", line 795, in ? main() File "../../setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "~wrk/Python-2.2.2/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "~wrk/Python-2.2.2/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/python/lib/python2.2/config/Makefile (No such file or directory) make: *** [sharedmods] Error 1 PROBLEM ANALYSIS================== By looking the code inside sysconfig.py module, it is clear that the problem is generated by the first IF clause (starting at line 32), where the python_build variable is set: the path obtained by joining "Lib" to the argv0_path variable does not exist, since no directory named Lib exists in the (current) work directory. In fact the only existing directories are: - Grammar - Modules - Objects - Parser - Python - build WORKAROUND ============= Simply create a link to the Lib directory provided with Python 2.2.2, i.e. in my example: ln -s ../../Lib make make test make install ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-15 22:04 Message: Logged In: YES user_id=6380 I've been told that this has been fixed in distutils for 2.2.3 and 2.3, so I'll close this now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-05 14:12 Message: Logged In: YES user_id=6656 Well, it works for me. I can't tell you what revision of sysconfig.py I made my fix in, because CVS has just stopped working :-( It was shortly after 222 went out. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 13:52 Message: Logged In: YES user_id=6380 Could you find details about the fix? I still get failures when I build Python outside the src directory when there's no Python installation in /usr/local/. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-05 13:49 Message: Logged In: YES user_id=6656 I think I may have fixed this in CVS some time ago... (on the release22-maint branch). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 13:44 Message: Logged In: YES user_id=6380 Tres's patch may work, but I think creating a symlink in the build directory named "Lib" pointing to the source Lib directory just masks the real problem. What is the real problem? ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2003-05-05 11:17 Message: Logged In: YES user_id=127625 The following patch works for me (derived from davideb's work): --- Tools/Python2/configure.in:1.1.1.2 Fri May 2 08:36:31 2003 +++ Tools/Python2/configure.in Mon May 5 10:56:17 2003 @@ -2116,6 +2116,12 @@ done AC_MSG_RESULT(done) +AC_MSG_CHECKING(for Lib directory) +if test ! -d Lib; then + ln -s $srcdir/Lib +fi +AC_MSG_RESULT(done) + # generate output files AC_OUTPUT(Makefile.pre Modules/Setup.config) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 05:39 Message: Logged In: YES user_id=21627 Eventually, your change has to end up in Makefile, right? So I would suggest you start from there: Have configure generate a Makefile, and modify the Makefile so that it suits your needs. If you then don't know how to proceed, please attach both Makefile (the original and the modified one) to this report, and we'll see how to proceed. Most likely, for your change to show up in Makefile, it would have to appear in Makefile.pre, with likely no changes to configure.in/configure. Makefile.pre, in turn, is generated from Makefile.pre.in, so that your change most likely needs to appear in Makefile.pre.in. ---------------------------------------------------------------------- Comment By: Davide Di Blasi (davidedb) Date: 2002-10-28 05:16 Message: Logged In: YES user_id=633937 I'd like to help, but unfortunately I do not know the autoconf configuration file syntax (i.e. configure.in), where - I guess - the problem has to be solved. Yet, by looking at the provided configure script, I added the following lines (starting at line #7600): --------------------- echo $ac_n "checking for Lib directory""... $ac_c" 1>&6 echo "configure: checking for Lib directory" >&5 if test ! -d Lib; then ln -s $srcdir/Lib fi echo "$ac_t""done" 1>&6 --------------------- This works fine when using the VPATH feature as well as when building directly in the standard source directory. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 13:04 Message: Logged In: YES user_id=21627 Would you like to work on a patch that fixes this problem? The patch should support both the case of in-place building, and VPATH building. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 From noreply@sourceforge.net Fri May 16 04:11:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 20:11:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-738617 ] On Windows, os.listdir() throws incorrect exception Message-ID: Bugs item #738617, was opened at 2003-05-16 13: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=738617&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Thompson (mikethompson) Assigned to: Nobody/Anonymous (nobody) Summary: On Windows, os.listdir() throws incorrect exception Initial Comment: 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 os >>> os.listdir('c:\IMPOSSIBLE') Traceback (most recent call last): File "", line 2, in ? WindowsError: [Errno 3] The system cannot find the path specified: 'c:\IMPOSSIBLE/*.*' This is the wrong exception I would have thought. AIUI, WindowsError is thrown for uniquely Windows types of problems. Path not found is not unique to Windows. I would have expected an os.error exception to have been thrown together with an code of errno.ENOENT. This is what happens if I try to open() a non existent file. (Caution: I'm a python newbie and I could easily have missed something here -- If so sorry to waste your time) The deadly part about this bug is that WindowsError subclasses os.error, just the code changes (3 instead of 2). So my "except os.error" worked to catch the exception ... just the error code seemed wrong. Took be ages to figure it all out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738617&group_id=5470 From noreply@sourceforge.net Fri May 16 05:24:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 21:24:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-738361 ] crash error in glob.glob; windows + strange directories Message-ID: Bugs item #738361, was opened at 2003-05-15 11:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: crash error in glob.glob; windows + strange directories Initial Comment: I'm attaching a zip file containing a python file and directory structure to test this. I ran into this bug in real life work, so, as contrived as the bug test may look, it happens. I was writing a function which recurses through directories and does stuff with the files it finds. glob.glob() doesn't return any files inside a directory named [_] glob.glob() crashes on a directory named [A--_B]. I tried a few different combinations of characters inside brackets, but this was the only one I could get it to crash on. the crash happens during the regular expression compilation, as probably can be surmised by seeing the characters which cause it ( [] ). it also may be a combination of that and using \ as the directory delimiter since this is win32. File "C:\temp\globbug\bug.py", line 5, in test fs = glob.glob( path + '\*' ) File "C:\Python22\lib\glob.py", line 24, in glob list = glob(dirname) File "C:\Python22\lib\glob.py", line 37, in glob sublist = glob1(dirname, basename) File "C:\Python22\lib\glob.py", line 50, in glob1 return fnmatch.filter(names,pattern) File "C:\Python22\lib\fnmatch.py", line 47, in filter _cache[pat] = re.compile(res) File "C:\Python22\lib\sre.py", line 179, in compile return _compile(pattern, flags) File "C:\Python22\lib\sre.py", line 229, in _compile raise error, v # invalid expression sre_constants.error: bad character range ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 23:24 Message: Logged In: YES user_id=80475 This doesn't seem like a bug to me. Those strange names have the Unix style magic characters in them. Unfortunately, brackets are valid file/dir names in Windows. If anything were changed, I would prefer strengthening the magic character recognizer from: magic_check = re.compile('[*?[]') to something that can treat ill-formed bracket expressions as being non-magic. When posting a bug report, please avoid zip files and multiple test scripts. It is enough to include in the text of the report something like this: glob.glob('[_]/*') # fails to recognize a win directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 From noreply@sourceforge.net Fri May 16 05:41:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 21:41:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-738361 ] crash error in glob.glob; windows + strange directories Message-ID: Bugs item #738361, was opened at 2003-05-15 12:06 Message generated for change (Comment added) made by progoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: crash error in glob.glob; windows + strange directories Initial Comment: I'm attaching a zip file containing a python file and directory structure to test this. I ran into this bug in real life work, so, as contrived as the bug test may look, it happens. I was writing a function which recurses through directories and does stuff with the files it finds. glob.glob() doesn't return any files inside a directory named [_] glob.glob() crashes on a directory named [A--_B]. I tried a few different combinations of characters inside brackets, but this was the only one I could get it to crash on. the crash happens during the regular expression compilation, as probably can be surmised by seeing the characters which cause it ( [] ). it also may be a combination of that and using \ as the directory delimiter since this is win32. File "C:\temp\globbug\bug.py", line 5, in test fs = glob.glob( path + '\*' ) File "C:\Python22\lib\glob.py", line 24, in glob list = glob(dirname) File "C:\Python22\lib\glob.py", line 37, in glob sublist = glob1(dirname, basename) File "C:\Python22\lib\glob.py", line 50, in glob1 return fnmatch.filter(names,pattern) File "C:\Python22\lib\fnmatch.py", line 47, in filter _cache[pat] = re.compile(res) File "C:\Python22\lib\sre.py", line 179, in compile return _compile(pattern, flags) File "C:\Python22\lib\sre.py", line 229, in _compile raise error, v # invalid expression sre_constants.error: bad character range ---------------------------------------------------------------------- >Comment By: Steven Scott (progoth) Date: 2003-05-16 00:41 Message: Logged In: YES user_id=61663 brackets are valid file/dir names in unix, too. in fact, if I'm not mistaken, the only 2 characters not allowed in unix file names are / and \0. I don't see how it's not a bug if glob tries to read the files in a directory that exists and crashes (or doesn't read them). as for how it should be fixed, I have no idea. my patch isn't very elegant. btw, I just ran this on unix (after changing the \ to / in the test script) and the exact same behavior was exhibited. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 00:24 Message: Logged In: YES user_id=80475 This doesn't seem like a bug to me. Those strange names have the Unix style magic characters in them. Unfortunately, brackets are valid file/dir names in Windows. If anything were changed, I would prefer strengthening the magic character recognizer from: magic_check = re.compile('[*?[]') to something that can treat ill-formed bracket expressions as being non-magic. When posting a bug report, please avoid zip files and multiple test scripts. It is enough to include in the text of the report something like this: glob.glob('[_]/*') # fails to recognize a win directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 From noreply@sourceforge.net Fri May 16 05:42:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 21:42:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-738361 ] crash error in glob.glob; directories with brackets Message-ID: Bugs item #738361, was opened at 2003-05-15 12:06 Message generated for change (Settings changed) made by progoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) >Summary: crash error in glob.glob; directories with brackets Initial Comment: I'm attaching a zip file containing a python file and directory structure to test this. I ran into this bug in real life work, so, as contrived as the bug test may look, it happens. I was writing a function which recurses through directories and does stuff with the files it finds. glob.glob() doesn't return any files inside a directory named [_] glob.glob() crashes on a directory named [A--_B]. I tried a few different combinations of characters inside brackets, but this was the only one I could get it to crash on. the crash happens during the regular expression compilation, as probably can be surmised by seeing the characters which cause it ( [] ). it also may be a combination of that and using \ as the directory delimiter since this is win32. File "C:\temp\globbug\bug.py", line 5, in test fs = glob.glob( path + '\*' ) File "C:\Python22\lib\glob.py", line 24, in glob list = glob(dirname) File "C:\Python22\lib\glob.py", line 37, in glob sublist = glob1(dirname, basename) File "C:\Python22\lib\glob.py", line 50, in glob1 return fnmatch.filter(names,pattern) File "C:\Python22\lib\fnmatch.py", line 47, in filter _cache[pat] = re.compile(res) File "C:\Python22\lib\sre.py", line 179, in compile return _compile(pattern, flags) File "C:\Python22\lib\sre.py", line 229, in _compile raise error, v # invalid expression sre_constants.error: bad character range ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2003-05-16 00:41 Message: Logged In: YES user_id=61663 brackets are valid file/dir names in unix, too. in fact, if I'm not mistaken, the only 2 characters not allowed in unix file names are / and \0. I don't see how it's not a bug if glob tries to read the files in a directory that exists and crashes (or doesn't read them). as for how it should be fixed, I have no idea. my patch isn't very elegant. btw, I just ran this on unix (after changing the \ to / in the test script) and the exact same behavior was exhibited. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 00:24 Message: Logged In: YES user_id=80475 This doesn't seem like a bug to me. Those strange names have the Unix style magic characters in them. Unfortunately, brackets are valid file/dir names in Windows. If anything were changed, I would prefer strengthening the magic character recognizer from: magic_check = re.compile('[*?[]') to something that can treat ill-formed bracket expressions as being non-magic. When posting a bug report, please avoid zip files and multiple test scripts. It is enough to include in the text of the report something like this: glob.glob('[_]/*') # fails to recognize a win directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 From noreply@sourceforge.net Fri May 16 06:17:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 22:17:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-735274 ] FILEMODE not honoured Message-ID: Bugs item #735274, was opened at 2003-05-09 17:07 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735274&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: FILEMODE not honoured Initial Comment: The Python build process doesn't honour the FILEMODE setting in Makefile.pre.in (or passed in at install time with "make FILEMODE=664 install") because configure sets the install command to an explicit "${INSTALL} -m 644" in stead of to "${INSTALL} -m ${FILEMODE}". DIRMODE and EXEMODE are handled correctly. Please let me know whether you agree and assign back to me, if you agree I'll put the changes in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 22:40 Message: Logged In: YES user_id=21627 I'm probably missing something: Where precisely is EXEMODE being used? As for FILEMODE: Is it important that this is honored? Users wanting to override this can also override INSTALL_DATA instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735274&group_id=5470 From noreply@sourceforge.net Fri May 16 19:20:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 11:20:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-738361 ] crash error in glob.glob; directories with brackets Message-ID: Bugs item #738361, was opened at 2003-05-15 11:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: crash error in glob.glob; directories with brackets Initial Comment: I'm attaching a zip file containing a python file and directory structure to test this. I ran into this bug in real life work, so, as contrived as the bug test may look, it happens. I was writing a function which recurses through directories and does stuff with the files it finds. glob.glob() doesn't return any files inside a directory named [_] glob.glob() crashes on a directory named [A--_B]. I tried a few different combinations of characters inside brackets, but this was the only one I could get it to crash on. the crash happens during the regular expression compilation, as probably can be surmised by seeing the characters which cause it ( [] ). it also may be a combination of that and using \ as the directory delimiter since this is win32. File "C:\temp\globbug\bug.py", line 5, in test fs = glob.glob( path + '\*' ) File "C:\Python22\lib\glob.py", line 24, in glob list = glob(dirname) File "C:\Python22\lib\glob.py", line 37, in glob sublist = glob1(dirname, basename) File "C:\Python22\lib\glob.py", line 50, in glob1 return fnmatch.filter(names,pattern) File "C:\Python22\lib\fnmatch.py", line 47, in filter _cache[pat] = re.compile(res) File "C:\Python22\lib\sre.py", line 179, in compile return _compile(pattern, flags) File "C:\Python22\lib\sre.py", line 229, in _compile raise error, v # invalid expression sre_constants.error: bad character range ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 13:20 Message: Logged In: YES user_id=80475 Okay. See if you can come-up with a more elegant patch that only touches the glob module. If you can see a straight-forward way to test it, then some unittests would be nice also. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2003-05-15 23:41 Message: Logged In: YES user_id=61663 brackets are valid file/dir names in unix, too. in fact, if I'm not mistaken, the only 2 characters not allowed in unix file names are / and \0. I don't see how it's not a bug if glob tries to read the files in a directory that exists and crashes (or doesn't read them). as for how it should be fixed, I have no idea. my patch isn't very elegant. btw, I just ran this on unix (after changing the \ to / in the test script) and the exact same behavior was exhibited. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 23:24 Message: Logged In: YES user_id=80475 This doesn't seem like a bug to me. Those strange names have the Unix style magic characters in them. Unfortunately, brackets are valid file/dir names in Windows. If anything were changed, I would prefer strengthening the magic character recognizer from: magic_check = re.compile('[*?[]') to something that can treat ill-formed bracket expressions as being non-magic. When posting a bug report, please avoid zip files and multiple test scripts. It is enough to include in the text of the report something like this: glob.glob('[_]/*') # fails to recognize a win directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 From noreply@sourceforge.net Fri May 16 19:49:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 11:49:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-735293 ] Command line timeit.py sets sys.path badly Message-ID: Bugs item #735293, was opened at 2003-05-09 10:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) >Assigned to: Guido van Rossum (gvanrossum) Summary: Command line timeit.py sets sys.path badly Initial Comment: Running timeit.py from the command line results in the directory containing timeit.py (ie, the standard Python library) being added to sys.path, and the current directory *not* being. To test, create a file mymod.py in the current directory, containing def test(): "Stupid test function" L = [] for i in range(100): L.append(i) Now, execute \Apps\Python\Lib\timeit.py -s "import mymod" "mymod.test()" Result is Traceback (most recent call last): File "\Apps\Python\Lib\timeit.py", line 245, in main x = t.timeit(number) File "\Apps\Python\Lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "", line 3, in inner import mymod ImportError: No module named mymod It's possible to work around this, either by setting PYTHONPATH in the environment to ".", or by adding "import sys; sys.path.insert(0, '.')" to the code in the -s option. But neither is a particularly attractive solution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 From noreply@sourceforge.net Fri May 16 20:03:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 12:03:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-735293 ] Command line timeit.py sets sys.path badly Message-ID: Bugs item #735293, was opened at 2003-05-09 11:36 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Guido van Rossum (gvanrossum) Summary: Command line timeit.py sets sys.path badly Initial Comment: Running timeit.py from the command line results in the directory containing timeit.py (ie, the standard Python library) being added to sys.path, and the current directory *not* being. To test, create a file mymod.py in the current directory, containing def test(): "Stupid test function" L = [] for i in range(100): L.append(i) Now, execute \Apps\Python\Lib\timeit.py -s "import mymod" "mymod.test()" Result is Traceback (most recent call last): File "\Apps\Python\Lib\timeit.py", line 245, in main x = t.timeit(number) File "\Apps\Python\Lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "", line 3, in inner import mymod ImportError: No module named mymod It's possible to work around this, either by setting PYTHONPATH in the environment to ".", or by adding "import sys; sys.path.insert(0, '.')" to the code in the -s option. But neither is a particularly attractive solution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-16 15:03 Message: Logged In: YES user_id=6380 Good point. Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 From noreply@sourceforge.net Fri May 16 20:32:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 12:32:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-738361 ] crash error in glob.glob; directories with brackets Message-ID: Bugs item #738361, was opened at 2003-05-15 12:06 Message generated for change (Comment added) made by progoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: crash error in glob.glob; directories with brackets Initial Comment: I'm attaching a zip file containing a python file and directory structure to test this. I ran into this bug in real life work, so, as contrived as the bug test may look, it happens. I was writing a function which recurses through directories and does stuff with the files it finds. glob.glob() doesn't return any files inside a directory named [_] glob.glob() crashes on a directory named [A--_B]. I tried a few different combinations of characters inside brackets, but this was the only one I could get it to crash on. the crash happens during the regular expression compilation, as probably can be surmised by seeing the characters which cause it ( [] ). it also may be a combination of that and using \ as the directory delimiter since this is win32. File "C:\temp\globbug\bug.py", line 5, in test fs = glob.glob( path + '\*' ) File "C:\Python22\lib\glob.py", line 24, in glob list = glob(dirname) File "C:\Python22\lib\glob.py", line 37, in glob sublist = glob1(dirname, basename) File "C:\Python22\lib\glob.py", line 50, in glob1 return fnmatch.filter(names,pattern) File "C:\Python22\lib\fnmatch.py", line 47, in filter _cache[pat] = re.compile(res) File "C:\Python22\lib\sre.py", line 179, in compile return _compile(pattern, flags) File "C:\Python22\lib\sre.py", line 229, in _compile raise error, v # invalid expression sre_constants.error: bad character range ---------------------------------------------------------------------- >Comment By: Steven Scott (progoth) Date: 2003-05-16 15:32 Message: Logged In: YES user_id=61663 So a co-worker pointed out that you could have directorys like mine, but say, numbered: [A--_B]1 [A--_B]2 etc say you wanted a pattern like '[A--_B]?' to get them all....that's not a valid directory, so it definitely needs to do some wildcard expansion...but it doesn't need to mess with what's inside the brackets. fnmatch probably shouldn't throw an exception in any case...regardless, we're of the opinion that the only logical way around this issue of wildcard characters in filenames is to have the programmer escape stuff manually. so r"\[A--_B]?" would be what is needed. python/glob/fnmatch can't read the programmer's mind in a pattern with wildcards which ones are supposed to be pattern or not. to take this route, fnmatch would have to be modified to recognize characters that are \-escaped, because it doesn't at the moment. or maybe that's not the best solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 14:20 Message: Logged In: YES user_id=80475 Okay. See if you can come-up with a more elegant patch that only touches the glob module. If you can see a straight-forward way to test it, then some unittests would be nice also. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2003-05-16 00:41 Message: Logged In: YES user_id=61663 brackets are valid file/dir names in unix, too. in fact, if I'm not mistaken, the only 2 characters not allowed in unix file names are / and \0. I don't see how it's not a bug if glob tries to read the files in a directory that exists and crashes (or doesn't read them). as for how it should be fixed, I have no idea. my patch isn't very elegant. btw, I just ran this on unix (after changing the \ to / in the test script) and the exact same behavior was exhibited. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 00:24 Message: Logged In: YES user_id=80475 This doesn't seem like a bug to me. Those strange names have the Unix style magic characters in them. Unfortunately, brackets are valid file/dir names in Windows. If anything were changed, I would prefer strengthening the magic character recognizer from: magic_check = re.compile('[*?[]') to something that can treat ill-formed bracket expressions as being non-magic. When posting a bug report, please avoid zip files and multiple test scripts. It is enough to include in the text of the report something like this: glob.glob('[_]/*') # fails to recognize a win directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 From noreply@sourceforge.net Fri May 16 22:05:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 14:05:13 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-738948 ] Logic Variable Thread Synchronization Message-ID: Feature Requests item #738948, was opened at 2003-05-16 14:05 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=738948&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Bowery (jabowery) Assigned to: Nobody/Anonymous (nobody) Summary: Logic Variable Thread Synchronization Initial Comment: See the attached and very rought PEP. Basically if you want to see the idea, read section 2.5.1 at: ftp://ftp.ps.uni-sb.de/pub/papers/ProgrammingSysLab/TOPLAS99.ps.gz The abstract of that paper is at: http://www.mozart-oz.org/papers/abstracts/TOPLAS99.html The abstarct of the PEP is as follows: Stackless Python [1] is an ideal environment within which to implement logic variables for thread synchroniziation [2]. The 3 additions required for this are 1) the addition of the "unknown" keyword that declares a logic variable, 2) the "final" keyword that declares a logic variable to be single- assignment and 3) the "=:=" operator that performs a unification of a logic variable with an expression. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=738948&group_id=5470 From noreply@sourceforge.net Fri May 16 23:18:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 15:18:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-738973 ] urllib2 CacheFTPHandler doesn't work on multiple dirs Message-ID: Bugs item #738973, was opened at 2003-05-16 15:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=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: Nobody/Anonymous (nobody) 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" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738973&group_id=5470 From noreply@sourceforge.net Sat May 17 00:30:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 16:30:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules Message-ID: Bugs item #411881, was opened at 2001-03-28 04:58 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Skip Montanaro (montanaro) Summary: Use of "except:" in modules Initial Comment: A large amount of modules in the standard library use "except:" instead of specifying the exceptions to be caught. In some cases this may be correct, but I think in most cases this not true and this may cause problems. Here's the list of modules, which I got by doing: grep "except:" *.py | cut -f 1 -d " " | sort | uniq Bastion.py CGIHTTPServer.py Cookie.py SocketServer.py anydbm.py asyncore.py bdb.py cgi.py chunk.py cmd.py code.py compileall.py doctest.py fileinput.py formatter.py getpass.py htmllib.py imaplib.py inspect.py locale.py locale.py mailcap.py mhlib.py mimetools.py mimify.py os.py pdb.py popen2.py posixfile.py pre.py pstats.py pty.py pyclbr.py pydoc.py repr.py rexec.py rfc822.py shelve.py shutil.py tempfile.py threading.py traceback.py types.py unittest.py urllib.py zipfile.py ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:30 Message: Logged In: YES user_id=357491 threading.py is clear. It's blanket exceptions are for printing debug output since exceptions in threads don't get passed back to the original frame anyway. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-13 20:15 Message: Logged In: YES user_id=44345 checked in fileinput.py (v 1.15) with three except:'s tightened up. The comment in the code about IOError notwithstanding, I don't see how any of the three situations would have caught anything other than OSError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-12 12:58 Message: Logged In: YES user_id=44345 Note that this particular item was expected to be an ongoing item, with no obvious closure. Some of the bare excepts will have subtle ramifications, and it's not always obvious what specific exceptions should be caught. I've made a few changes to my local source tree which I should check in. Rather than opening new tracker items, I believe those with checkin privileges should correct those flaws they identify and attach a comment which will alert those monitoring the item. Those people without checkin privileges should just attach a patch with a note. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 00:22 Message: Logged In: YES user_id=21627 My proposal would be to track this under a different issue: Terry, if you volunteer, please produce a new list of offenders (perhaps in an attachment to the report so it can be updated), and attach any fixes that you have to that report. People with CVS write access can then apply those patches and delete them from the report. If you do so, please post the new issue number in this report, so we have a link. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 11:16 Message: Logged In: YES user_id=593130 Remove types.py from the list. As distributed with 2.2.1, it has 5 'except xxxError:' statements but no offending bare except:'s. Skip (or anyone else): if/when you pursue this, I volunteer to do occasional sleuthing and send reports with suggestions and/or questions. Example: getpass.py has one 'offense': try: fd = sys.stdin.fileno() except: return default_getpass(prompt) According to lib doc 2.2.8 File Objects (as I interpret) fileno () should either work without exception or *not* be implemented. Suggestion: insert AttributeError . Question: do we protect against pseudofile objects that ignore doc and have fake .fileno() that raises NotImplementedError or whatever? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-22 22:02 Message: Logged In: YES user_id=44345 as partial fix, checked in changes for the following modules: mimetools.py (1.24) popen2.py (1.23) quopripy (1.19) CGIHTTPServer.py (1.22) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-20 13:24 Message: Logged In: YES user_id=44345 Here is a context diff with proposed changes for the following modules: CGIHTTPServer, cgi, cmd, code, fileinput, httplib, inspect, locale, mimetools, popen2, quopri ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-11 08:06 Message: Logged In: YES user_id=21627 Fixed urllib in 1.131 and types in 1.19. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-04 00:11 Message: Logged In: YES user_id=3066 Fixed modules mhlib and rfc822 (SF is having a problem generating the checkin emails, though). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-05-11 12:40 Message: Logged In: YES user_id=3066 OK, I've fixed up a few more modules: anydbm chunk formatter htmllib mailcap pre pty I made one change to asyncore as well, but other bare except clauses remain there; I'm not sufficiently familiar with that code to just go digging into those. I also fixed an infraction in pstats, but left others for now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-23 01:14 Message: Logged In: YES user_id=31435 Ping's intent is that pydoc work under versions of Python as early as 1.5.2, so that sys._getframe is off-limits in pydoc and its supporting code (like inspect.py). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-23 00:32 Message: Logged In: YES user_id=21627 For inspect.py, why is it necessary to keep the old code at all? My proposal: remove currentframe altogether, and do currentframe = sys._getframe unconditionally. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-22 07:52 Message: Logged In: YES user_id=32065 I submitted a 4th patch. I'm starting to run out of easy cases... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-04-19 02:15 Message: Logged In: YES user_id=44345 I believe the following patch is correct for the try/except in inspect.currentframe. Note that it fixes two problems. One, it avoids a bare except. Two, it gets rid of a string argument to the raise statement (string exceptions are now deprecated, right?). *** /tmp/skip/inspect.py Thu Apr 19 04:13:36 2001 --- /tmp/skip/inspect.py.~1.16~ Thu Apr 19 04:13:36 2001 *************** *** 643,650 **** def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! 1/0 ! except ZeroDivisionError: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe --- 643,650 ---- def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! raise 'catch me' ! except: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-17 08:27 Message: Logged In: YES user_id=32065 inspect.py uses sys_getframe if it's there, the other code is for backwards compatibility. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 10:24 Message: Logged In: YES user_id=6380 Actually, inspect.py should use sys._getframe()! And yes, KeyboardError is definitely one of the reasons why this is such a bad idiom... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-04-11 10:15 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-04-11 10:13 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:45 Message: Logged In: YES user_id=6380 I've applied the three patches you supplied. I agree with Martin that to do this right we'll have to tread carefully. But please go on! (No way more of this will find its way into 2.1 though.) ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-03-30 02:54 Message: Logged In: YES user_id=32065 inspect.py should be removed from this list, the use is correct. In general, I just submitted this bug so that when people are editing a module they'll notice these things, since in some cases only someone who knows the code very well can know if the "expect:" is needed or not. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-29 22:59 Message: Logged In: YES user_id=21627 Can you identify modules where catching everything is incorrect, and propose changes to correct them. This should be done one-by-one, with careful analysis in each case, and may take well months or years to complete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 From noreply@sourceforge.net Sat May 17 00:33:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 16:33:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-416526 ] Regular expression tests: SEGV on Mac OS Message-ID: Bugs item #416526, was opened at 2001-04-16 14:09 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470 Category: Regular Expressions Group: Platform-specific >Status: Closed >Resolution: Out of Date Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: Regular expression tests: SEGV on Mac OS Initial Comment: The regular expression regression tests 'test_re' causes a SEGV failure on Mac OS X version 10.0.1 when using Python 2.1c2 (and earlier). This is caused by the test trying to recurse 50,000 levels deep. Workaround: A workaround is to limit how deep the regular expression library can recurse (this is already done for Win32). This can be achieved by changing file './Modules/_sre.c' using the following patch: --- ./orig/_sre.c Sun Apr 15 19:00:58 2001 +++ ./new/_sre.c Mon Apr 16 21:39:29 2001 @@ -75,6 +75,9 @@ Win64 (MS_WIN64), Linux64 (__LP64__), Monterey (64-bit AIX) (_LP64) */ /* FIXME: maybe the limit should be 40000 / sizeof(void*) ? */ #define USE_RECURSION_LIMIT 7500 +#elif defined(__APPLE_CC__) +/* Apple 'cc' compiler eg. for Mac OS X */ +#define USE_RECURSION_LIMIT 4000 #else #define USE_RECURSION_LIMIT 10000 #endif ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:33 Message: Logged In: YES user_id=357491 This was fixed a while back in regrtest.py by changing the stack size on OS X to a more reasonable size. Closing this as out of date. ---------------------------------------------------------------------- Comment By: Bill Bumgarner (bbum) Date: 2002-12-04 14:09 Message: Logged In: YES user_id=103811 Bad workaround. A better workaround is to set a reasonable stacksize limite; the 'out of the box' stacksize limit is stupid low. Try running 'unlimit' before the regression tests -- the test will pass fine on OS X in that situation. Limiting the recursion limit on OS X simply because the [easily changed] out of the box stack size is relatively small would be a very bad fix indeed. I have run into a number of situations where I programatically generate regular expressions that can be extremely complex. They explode on OS X without the 'unlimit' and work fine once the stack has been set to a reasonable maximum size. I would be extremely unhappy if those expressions were to *always* break on OS X due to a change to the internals of python that assume the stack will always be tiny. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-18 22:16 Message: Logged In: NO same problem on 10.1.4 james@i-mech.com ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 20:49 Message: Logged In: YES user_id=6380 /F is unavailable, I don't want this to hold up the 2.2a2 release, so I'm lowering the priority because it doesn't affect Linux or Windows. (Remember, no bugs/patches with priority >= 7 should be left when doing a release.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-01 17:41 Message: Logged In: NO >An alternate (and perhaps better) workaround could be to increase the stack size on Mac OS X. it's been tried and shot down as a will not fix. :-( instead of +#elif defined(__APPLE_CC__) perhaps we should use __APPLE__ as per the documentation: There are two relatively new macros: __APPLE__ and __APPLE_CC__.The former refers to any Apple platform, though at present it is only predefined in Apple's gcc-based Mac OS X and Mac OS X Server compilers. The value of the latter is an integer that corresponds to the version number of the compiler. This should allow one to distinguish, for example, between compilers based on the same version of gcc, but with different bug fixes or features. At present, larger values denote (chronologically) later compilers. - D ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-26 15:01 Message: Logged In: YES user_id=38376 An alternate (and perhaps better) workaround could be to increase the stack size on Mac OS X. But in either case, my plan is to get rid of the recursion limit in 2.2 (stackless SRE may still run out of memory, but it shouldn't have to run out of stack). Cheers /F ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2001-04-17 16:52 Message: Logged In: YES user_id=80173 Instead of relying on a compiler variable, we should probably set a environment variable as part of the ./configure and use that to determine when to reduce the USE_RECURSION_LIMIT. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470 From noreply@sourceforge.net Sat May 17 00:43:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 16:43:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-417833 ] pydoc HTTP reload failure Message-ID: Bugs item #417833, was opened at 2001-04-21 07:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Ka-Ping Yee (ping) Summary: pydoc HTTP reload failure Initial Comment: pydoc, when run as a web server, can't cope with reloads of modules which use 'from Package import Module' syntax for imports. To reproduce: * extract the attached DemonstratePydocBug tarchive into your Python 2.1 directory * python -c Lib\pydoc.py -p 8192 * visit http://localhost:8192/DemonstratePydocBug.html The rest of the instructions are there. Demonstrated on Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32. Funnily enough, there's no problem with trying the following under Python interactively: Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails I'm dropping additional debugging code into pydoc.py to see if I can figure out what's going on. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:43 Message: Logged In: YES user_id=357491 Just as an update, this still seeems to be an issue in Python 2.3b1 w/ version 1.82 of pydoc ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:15 Message: Logged In: YES user_id=59803 Using pydoc in the interpreter doesn't tickle any of these bugs, so hopefully I can narrow my focus down to the difference in handling between serve() and help(). Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> pydoc.help Welcome to Python 2.1! This is the online help utility. [...] help> modules Please wait a moment while I gather a list of all available modules... [list of modules] Enter any module name to get more help. Or, type "modules spam" to search for modules whose descriptions contain the word "spam". help> DemonstratePydocBug.ReloadFails Help on module DemonstratePydocBug.ReloadFails in DemonstratePydocBug: NAME DemonstratePydocBug.ReloadFails FILE c:\python21\lib\demonstratepydocbug\reloadfails.py [...] help> DemonstratePydocBug.TryThis Help on module DemonstratePydocBug.TryThis in DemonstratePydocBug: NAME DemonstratePydocBug.TryThis [...] ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 08:09 Message: Logged In: YES user_id=59803 Yet another demonstration case: DemonstratePydocBug/TryThis.py: import DemonstratePydocBug.Target Target = DemonstratePydocBug.Target This gives us a local Target variable, same as 'from DemonstratePydocBug import Target'. Pydoc barfs on this on the very first load. The traceback I hacked into pydoc claims: Traceback (most recent call last): File "C:\Python21\Lib\pydoc.py", line 223, in safeimport module = __import__(path) File "c:\python21\lib\DemonstratePydocBug\TryThis.py", line 9, in ? Target = DemonstratePydocBug.Target AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' In the interpreter, everything's fine with both techniques for getting Target: C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import Target >>> Target >>> C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.Target >>> Target = DemonstratePydocBug.Target >>> Target >>> ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:58 Message: Logged In: YES user_id=59803 WHOA. Belay that. I screwed up trying to run too many tests in a row without shutting down the interpreter. Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> DemonstratePydocBug.Target Traceback (most recent call last): File "", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' >>> import DemonstratePydocBug.Target >>> DemonstratePydocBug.Target >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target FILE c:\python21\lib\demonstratepydocbug\target.py DESCRIPTION Target: module to help demonstrate the pydoc reload bug. See the docstring in __init__.py for full details. Reloading the description of this module in pydoc should work, but that's hardly unusual because it doesn't import *anything*. Try ReloadWorks and ReloadFails, instead. DATA __file__ = r'c:\python21 \lib\DemonstratePydocBug\Target.pyc' __name__ = 'DemonstratePydocBug.Target' >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target ... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:55 Message: Logged In: YES user_id=59803 >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) ... we get good stuff... >>> print DemonstratePydocBug.ReloadFails2 >>> pydoc.help(DemonstratePydocBug.ReloadFails2) ... we get good stuff... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:43 Message: Logged In: YES user_id=59803 I've found another demonstration case. Noting that from package import module gives you a variable called 'module', whilst import package.module gives you a variable called 'package', I thought I'd try out another import syntax which wouldn't break code that was trying out the first option: import package.module as module This also works under the Python 2.1 interpreter but breaks pydoc 1.38. I've attached an updated demonstration tarchive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 From noreply@sourceforge.net Sat May 17 00:50:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 16:50:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-418626 ] maximum recursion limit exceeded (2.1) Message-ID: Bugs item #418626, was opened at 2001-04-24 12:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded (2.1) Initial Comment: % /usr/bin/env python2.1 Python 2.1 (#2, Apr 24 2001, 11:33:06) [GCC 2.95.3 20010315 (release)] on hp-uxB Type "copyright", "credits" or "license" for more information. >>> % uname -a HP-UX wshelley B.11.00 A 9000/785 2014123772 two-user license % rebug.py Traceback (most recent call last): File "rebug.py", line 205, in ? re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output, re.S) File "/usr/local/lib/python2.1/sre.py", line 57, in search return _compile(pattern, flags).search(string) RuntimeError: maximum recursion limit exceeded rebug.py script works correctly using python1.5.2 I submitted this bug as a followup to [ #215696 ] sre RuntimeError when .*? matches >16K string ##### The following is the rebug.py file #!/usr/bin/env python2.1 import re output = """Using == Data Table == s m:d mb 3.300000 0.000104772187944365 -1.23330767339032e-15 3.200000 0.000103862130408037 -1.23481086168441e-15 3.100000 0.000102831826202984 -1.23643366708223e-15 3.000000 0.000101671354638586 -1.23819069775402e-15 2.900000 0.000100370082245968 -1.24009908383179e-15 2.800000 9.89166376398503e-05 -1.24217904419247e-15 2.700000 9.72988932844521e-05 -1.24445461136295e-15 2.600000 9.55039568198016e-05 -1.24695456774457e-15 2.500000 9.3518175238995e-05 -1.24971366756711e-15 2.400000 9.13271559565959e-05 -1.25277425005882e-15 2.300000 8.89158096852735e-05 -1.25618839559713e-15 2.200000 8.62684210547775e-05 -1.26002084671538e-15 2.100000 8.33687540802062e-05 -1.26435302405962e-15 2.000000 8.02002009414518e-05 -1.26928863786894e-15 1.900000 7.67459841300842e-05 -1.27496167015724e-15 1.800000 7.29894239935539e-05 -1.28154795600633e-15 1.700000 6.89142864097651e-05 -1.28928236065365e-15 1.600000 6.45052296412595e-05 -1.29848488989922e-15 1.500000 5.97483776126083e-05 -1.30960148694006e-15 1.400000 5.46320649249439e-05 -1.32326977154928e-15 1.300000 4.91478435825781e-05 -1.3404286750276e-15 1.200000 4.32919623998454e-05 -1.36250830892367e-15 1.100000 3.70678871330223e-05 -1.39177202537724e-15 1.000000 3.04915786576429e-05 -1.43195494399345e-15 0.900000 2.36052666077545e-05 -1.48947100843164e-15 0.800000 1.65202853321069e-05 -1.57551564136398e-15 0.700000 9.56073716566518e-06 -1.70791288744525e-15 0.600000 3.67125710597e-06 -1.89923336361812e-15 0.500000 6.00021904261974e-07 -2.08381565027337e-15 0.400000 4.27864345038415e-08 -2.14973379503184e-15 0.300000 2.5741570279509e-09 -2.15852923041729e-15 0.200000 1.60325700603365e-10 -2.15762110254924e-15 0.100000 1.10181009347061e-11 -2.15430351925385e-15 0.000000 9.18460199298261e-13 -2.14607756126421e-15 -0.100000 8.2907448480307e-14 -2.13154544128925e-15 -0.200000 9.49291906644266e-15 -2.09562596113738e-15 -0.300000 2.57398712712903e-15 -1.89144055818718e-15 -0.400000 1.23896929747012e-15 -1.18482371296596e-15 -0.500000 4.77088843470797e-16 -4.74259070979461e-16 3.300000 0.000725333230235404 -1.60279744215745e-14 3.200000 0.000698989627849489 -1.57983897758426e-14 3.100000 0.000672395787137216 -1.55721529060957e-14 3.000000 0.000645566845212758 -1.53549883971193e-14 2.900000 0.000618516906916818 -1.51624220311135e-14 2.800000 0.000591259277466284 -1.50347782956977e-14 2.700000 0.000563806714724985 -1.5069525306854e-14 2.600000 0.000536171704020601 -1.54848062262748e-14 2.500000 0.000508366761845922 -1.67334737461837e-14 2.400000 0.000480404778779427 -1.96904798125589e-14 2.300000 0.00045229941701671 -2.59347024715496e-14 2.200000 0.000424065584744255 -3.81354821168744e-14 2.100000 0.000395720019338978 -6.05316531752639e-14 2.000000 0.000367282025836478 -9.9457021513997e-14 1.900000 0.000338774439198852 -1.63825993533288e-13 1.800000 0.000310224913488982 -2.65456611717139e-13 1.700000 0.000281667696431468 -4.19089961445906e-13 1.600000 0.000253146138686846 -6.4197984099406e-13 1.500000 0.000224716340367884 -9.52983499747302e-13 1.400000 0.00019645260393449 -1.37117106753005e-12 1.300000 0.000168455842857815 -1.9140171376089e-12 1.200000 0.000140866992561325 -2.5949957749272e-12 1.100000 0.000113889209694637 -3.419066099784e-12 1.000000 8.78261401150504e-05 -4.36958009251635e-12 0.900000 6.31506490822963e-05 -5.36461118003355e-12 0.800000 4.06312963119592e-05 -6.12577475587495e-12 0.700000 2.15481889941145e-05 -5.92418822150058e-12 0.600000 7.87604367966821e-06 -3.80859906972703e-12 0.500000 1.3904896761789e-06 -9.79870732426348e-13 0.400000 1.06064890626322e-07 -9.39992702457847e-14 0.300000 6.34950130197645e-09 -1.65503941397823e-14 0.200000 3.88292805625561e-10 -1.16204226732226e-14 0.100000 2.57865399432747e-11 -1.11870703136006e-14 0.000000 2.05458930149398e-12 -1.09482596289954e-14 -0.100000 1.85578779234532e-13 -1.06729449780495e-14 -0.200000 2.5577583052963e-14 -1.02232392679007e-14 -0.300000 1.05769385343133e-14 -9.2322860676878e-15 -0.400000 8.00273522170935e-15 -7.88228414475344e-15 -0.500000 6.51965630664677e-15 -6.50815076902941e-15 3.300000 0.000778073989265561 -1.65574096734398e-07 3.200000 0.00074963150963251 -1.92244746339178e-07 3.100000 0.000721015586364691 -2.21197891556889e-07 3.000000 0.000692226507232058 -2.52254070463242e-07 2.900000 0.000663264988754168 -2.85152554002688e-07 2.800000 0.000634132321079485 -3.19546222567145e-07 2.700000 0.000604830546549725 -3.54998299569146e-07 2.600000 0.000575362679604795 -3.90981285317844e-07 2.500000 0.000545732977654778 -4.26878409205096e-07 2.400000 0.000515947275272665 -4.61987879332959e-07 2.300000 0.000486013397947319 -4.95530155074015e-07 2.200000 0.000455941677304999 -5.26658398699649e-07 2.100000 0.000425745598153737 -5.54472176489517e-07 2.000000 0.000395442620520435 -5.78034377120716e-07 1.900000 0.000365055239615154 -5.96391194651538e-07 1.800000 0.000334612377612625 -6.0859488246625e-07 1.700000 0.000304151250425071 -6.13728816719563e-07 1.600000 0.000273719932661724 -6.1093419812057e-07 1.500000 0.000243380977243086 -5.99437433988553e-07 1.400000 0.000213216675616044 -5.78576796961394e-07 1.300000 0.000183336956663227 -5.47826196051382e-07 1.200000 0.000153891700661593 -5.06812695554088e-07 1.100000 0.000125090796710056 -4.55323667088038e-07 1.000000 9.7238530664174e-05 -3.9330616509577e-07 0.900000 7.07959411929754e-05 -3.20910962327376e-07 0.800000 4.64992533700793e-05 -2.38877973057319e-07 0.700000 2.55795422135307e-05 -1.50458199069334e-07 0.600000 1.00314893206752e-05 -6.74343626580743e-08 0.500000 2.00947524041218e-06 -1.48839482947924e-08 0.400000 1.67232105200131e-07 -1.2816627677716e-09 0.300000 1.00809637284154e-08 -7.82708572696571e-11 0.200000 6.12196843592758e-10 -4.83619605089934e-12 0.100000 4.0027953235145e-11 -3.39466185939354e-13 0.000000 3.1163322565507e-12 -4.38427713973686e-14 -0.100000 2.82036148373174e-13 -2.01235539818538e-14 -0.200000 4.04726306794353e-14 -1.75747562532315e-14 -0.300000 1.83397331593843e-14 -1.63366924660679e-14 -0.400000 1.50709750319906e-14 -1.48901998089388e-14 -0.500000 1.34240392889815e-14 -1.34063683071726e-14 3.300000 0.000104772187944365 -1.23330767339032e-15 3.200000 0.000103862130408037 -1.23481086168441e-15 3.100000 0.000102831826202984 -1.23643366708223e-15 3.000000 0.000101671354638586 -1.23819069775402e-15 2.900000 0.000100370082245968 -1.24009908383179e-15 2.800000 9.89166376398503e-05 -1.24217904419247e-15 2.700000 9.72988932844521e-05 -1.24445461136295e-15 2.600000 9.55039568198016e-05 -1.24695456774457e-15 2.500000 9.3518175238995e-05 -1.24971366756711e-15 2.400000 9.13271559565959e-05 -1.25277425005882e-15 2.300000 8.89158096852735e-05 -1.25618839559713e-15 2.200000 8.62684210547775e-05 -1.26002084671538e-15 2.100000 8.33687540802062e-05 -1.26435302405962e-15 2.000000 8.02002009414518e-05 -1.26928863786894e-15 1.900000 7.67459841300842e-05 -1.27496167015724e-15 1.800000 7.29894239935539e-05 -1.28154795600633e-15 1.700000 6.89142864097651e-05 -1.28928236065365e-15 1.600000 6.45052296412595e-05 -1.29848488989922e-15 1.500000 5.97483776126083e-05 -1.30960148694006e-15 1.400000 5.46320649249439e-05 -1.32326977154928e-15 1.300000 4.91478435825781e-05 -1.3404286750276e-15 1.200000 4.32919623998454e-05 -1.36250830892367e-15 1.100000 3.70678871330223e-05 -1.39177202537724e-15 1.000000 3.04915786576429e-05 -1.43195494399345e-15 0.900000 2.36052666077545e-05 -1.48947100843164e-15 0.800000 1.65202853321069e-05 -1.57551564136398e-15 0.700000 9.56073716566518e-06 -1.70791288744525e-15 0.600000 3.67125710597e-06 -1.89923336361812e-15 0.500000 6.00021904261974e-07 -2.08381565027337e-15 0.400000 4.27864345038415e-08 -2.14973379503184e-15 0.300000 2.5741570279509e-09 -2.15852923041729e-15 0.200000 1.60325700603365e-10 -2.15762110254924e-15 0.100000 1.10181009347061e-11 -2.15430351925385e-15 0.000000 9.18460199298261e-13 -2.14607756126421e-15 -0.100000 8.2907448480307e-14 -2.13154544128925e-15 -0.200000 9.49291906644266e-15 -2.09562596113738e-15 -0.300000 2.57398712712903e-15 -1.89144055818718e-15 -0.400000 1.23896929747012e-15 -1.18482371296596e-15 -0.500000 4.77088843470797e-16 -4.74259070979461e-16 3.300000 0.000725333230235404 -1.60279744215745e-14 3.200000 0.000698989627849489 -1.57983897758426e-14 3.100000 0.000672395787137216 -1.55721529060957e-14 3.000000 0.000645566845212758 -1.53549883971193e-14 2.900000 0.000618516906916818 -1.51624220311135e-14 2.800000 0.000591259277466284 -1.50347782956977e-14 2.700000 0.000563806714724985 -1.5069525306854e-14 2.600000 0.000536171704020601 -1.54848062262748e-14 2.500000 0.000508366761845922 -1.67334737461837e-14 2.400000 0.000480404778779427 -1.96904798125589e-14 2.300000 0.00045229941701671 -2.59347024715496e-14 2.200000 0.000424065584744255 -3.81354821168744e-14 2.100000 0.000395720019338978 -6.05316531752639e-14 2.000000 0.000367282025836478 -9.9457021513997e-14 1.900000 0.000338774439198852 -1.63825993533288e-13 1.800000 0.000310224913488982 -2.65456611717139e-13 1.700000 0.000281667696431468 -4.19089961445906e-13 1.600000 0.000253146138686846 -6.4197984099406e-13 1.500000 0.000224716340367884 -9.52983499747302e-13 1.400000 0.00019645260393449 -1.37117106753005e-12 1.300000 0.000168455842857815 -1.9140171376089e-12 1.200000 0.000140866992561325 -2.5949957749272e-12 1.100000 0.000113889209694637 -3.419066099784e-12 1.000000 8.78261401150504e-05 -4.36958009251635e-12 0.900000 6.31506490822963e-05 -5.36461118003355e-12 0.800000 4.06312963119592e-05 -6.12577475587495e-12 0.700000 2.15481889941145e-05 -5.92418822150058e-12 0.600000 7.87604367966821e-06 -3.80859906972703e-12 0.500000 1.3904896761789e-06 -9.79870732426348e-13 0.400000 1.06064890626322e-07 -9.39992702457847e-14 0.300000 6.34950130197645e-09 -1.65503941397823e-14 0.200000 3.88292805625561e-10 -1.16204226732226e-14 0.100000 2.57865399432747e-11 -1.11870703136006e-14 0.000000 2.05458930149398e-12 -1.09482596289954e-14 -0.100000 1.85578779234532e-13 -1.06729449780495e-14 -0.200000 2.5577583052963e-14 -1.02232392679007e-14 -0.300000 1.05769385343133e-14 -9.2322860676878e-15 -0.400000 8.00273522170935e-15 -7.88228414475344e-15 -0.500000 6.51965630664677e-15 -6.50815076902941e-15 """ re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output, re.S) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:50 Message: Logged In: YES user_id=357491 Is this bug still a problem? No problem under OS X using 2.3b1. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-02 04:23 Message: Logged In: NO I have the same problem, running Python 2.1.3. It works well under Windows XP, but fails under Linux. Both Python 2.1.3. This is the pattern I am trying to match: ([\s,\S]*?) I use re.split in order to group code outside tables and code inside tables. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-24 20:28 Message: Logged In: YES user_id=31435 Assigned to /F. Works for me on Win98 under 2.1. Binding m to the re result and then printing print m.span(), len(output), m.span(1), m.span(2) yields (8, 12112) 12112 (25, 43) (44, 12111) Anonymous, this is a poor use for regexps: the code would be clearer, simpler and faster (plus it wouldn't blow up ) if you used basic string operations instead. The (.*?)\s*$ at the end is especially wasteful: you're teilling the regexp engine to do 12,000+ useless match attempts there, when all you *want* is the entire tail end of the string stripped of trailing whitespace. So just grab the tail end of the string directly and do string.rstrip() on it; saves 12,000+ useless matching attempts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470 From noreply@sourceforge.net Sat May 17 00:51:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 16:51:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-444514 ] raw-unicode-escape codec fails roundtrip Message-ID: Bugs item #444514, was opened at 2001-07-25 09:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 3 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: Martin v. Löwis (loewis) Summary: raw-unicode-escape codec fails roundtrip Initial Comment: On wide Python builds, the raw-unicode-escape codec fails the round-trip for non-BMP code points. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:51 Message: Logged In: YES user_id=357491 OK, I am reassigning to Martin as per MA's suggestion. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-05-12 02:28 Message: Logged In: YES user_id=38388 I haven't done anything in that direction and don't have the time to do now, so feel free to assign the bug report to someone else, e.g. Martin who has done most of the wide Unicode support. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 16:55 Message: Logged In: YES user_id=357491 Marc-Andre, is this bug still unresolved? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 03:47 Message: Logged In: YES user_id=38388 I'll look into this after I'm back from vacation on the 10.09. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 From noreply@sourceforge.net Sat May 17 00:52:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 16:52:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-450225 ] urljoin fails RFC tests Message-ID: Bugs item #450225, was opened at 2001-08-11 22:10 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) >Assigned to: Brett Cannon (bcannon) Summary: urljoin fails RFC tests Initial Comment: I've put together a test suite for Python's URLparse module, based on the tests in Appendix C of RFC2396 (the URI RFC). They're available at: http://lists.w3.org/Archives/Public/uri/2001Aug/ 0013.html The major problem seems to be that it treats queries and parameters as special components (not just normal parts of the path), making this related to: http://sourceforge.net/tracker/?group_id=5470& atid=105470&func=detail&aid=210834 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 17:35 Message: Logged In: YES user_id=357491 mbrierst is right. From C.1 of RFC 2396 (with http://a/b/c/d;p?q as the base): ?y = http://a/b/c/?y ;x = http://a/b/c/;x And notice how this contradicts RFC 1808 ( with as the base): ?y = ;x = So obviously there is a conflict here. And since RFC 2396 says "it revises and replaces the generic definitions in RFC 1738 and RFC 1808" (of which "generic" just means the actual syntax) this means that RFC 2396's solution should override. Now the issue is whether the patch for this is the right thing to do (I am ignoring if the patch is correct; have not tested it yet). This shouldn't break anything since the whole point of urlparse.urljoin is to have an abstracted way to create URIs without the user having to worry about all of these rules. So I say that it should be changed. Fred, do you mind if I reassign this patch to myself and deal with it? ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-03 13:02 Message: Logged In: YES user_id=670441 The two failing tests could not pass because RFC 1808 and RFC 2396 seem to conflict when a relative URI is given as just ;y or just ?y. RFC 2396 claims to update RFC 1808, so presumably it describes the correct behavior. The patch in this message (I can't upload it on sourceforge here for some reason) brings urljoin's behavior in line with RFC 2396, and changes the appropriate test cases. I think if you apply this patch this bug can be closed. Let me know what you think Index: python/dist/src/Lib/urlparse.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/urlparse.py,v retrieving revision 1.39 diff -c -r1.39 urlparse.py *** python/dist/src/Lib/urlparse.py 7 Jan 2003 02:09:16 -0000 1.39 --- python/dist/src/Lib/urlparse.py 3 Feb 2003 20:51:08 -0000 *************** *** 157,169 **** if path[:1] == '/': return urlunparse((scheme, netloc, path, params, query, fragment)) ! if not path: ! if not params: ! params = bparams ! if not query: ! query = bquery return urlunparse((scheme, netloc, bpath, ! params, query, fragment)) segments = bpath.split('/')[:-1] + path.split('/') # XXX The stuff below is bogus in various ways... if segments[-1] == '.': --- 157,165 ---- if path[:1] == '/': return urlunparse((scheme, netloc, path, params, query, fragment)) ! if not (path or params or query): return urlunparse((scheme, netloc, bpath, ! bparams, bquery, fragment)) segments = bpath.split('/')[:-1] + path.split('/') # XXX The stuff below is bogus in various ways... if segments[-1] == '.': Index: python/dist/src/Lib/test/test_urlparse.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_urlparse.py,v retrieving revision 1.11 diff -c -r1.11 test_urlparse.py *** python/dist/src/Lib/test/test_urlparse.py 6 Jan 2003 20:27:03 -0000 1.11 --- python/dist/src/Lib/test/test_urlparse.py 3 Feb 2003 20:51:12 -0000 *************** *** 54,59 **** --- 54,63 ---- self.assertEqual(urlparse.urlunparse(urlparse.urlparse(u)), u) def test_RFC1808(self): + # updated by RFC 2396 + # self.checkJoin(RFC1808_BASE, '?y', 'http://a/b/c/d;p?y') + # self.checkJoin(RFC1808_BASE, ';x', 'http://a/b/c/d;x') + # "normal" cases from RFC 1808: self.checkJoin(RFC1808_BASE, 'g:h', 'g:h') self.checkJoin(RFC1808_BASE, 'g', 'http://a/b/c/g') *************** *** 61,74 **** self.checkJoin(RFC1808_BASE, 'g/', 'http://a/b/c/g/') self.checkJoin(RFC1808_BASE, '/g', 'http://a/g') self.checkJoin(RFC1808_BASE, '//g', 'http://g') - self.checkJoin(RFC1808_BASE, '?y', 'http://a/b/c/d;p?y') self.checkJoin(RFC1808_BASE, 'g?y', 'http://a/b/c/g?y') self.checkJoin(RFC1808_BASE, 'g?y/./x', 'http://a/b/c/g?y/./x') self.checkJoin(RFC1808_BASE, '#s', 'http://a/b/c/d;p?q#s') self.checkJoin(RFC1808_BASE, 'g#s', 'http://a/b/c/g#s') self.checkJoin(RFC1808_BASE, 'g#s/./x', 'http://a/b/c/g#s/./x') self.checkJoin(RFC1808_BASE, 'g?y#s', 'http://a/b/c/g?y#s') - self.checkJoin(RFC1808_BASE, ';x', 'http://a/b/c/d;x') self.checkJoin(RFC1808_BASE, 'g;x', 'http://a/b/c/g;x') self.checkJoin(RFC1808_BASE, 'g;x?y#s', 'http://a/b/c/g;x?y#s') self.checkJoin(RFC1808_BASE, '.', 'http://a/b/c/') --- 65,76 ---- *************** *** 103,111 **** def test_RFC2396(self): # cases from RFC 2396 ! ### urlparse.py as of v 1.32 fails on these two ! #self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/?y') ! #self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/;x') self.checkJoin(RFC2396_BASE, 'g:h', 'g:h') self.checkJoin(RFC2396_BASE, 'g', 'http://a/b/c/g') --- 105,113 ---- def test_RFC2396(self): # cases from RFC 2396 ! # conflict with RFC 1808, tests commented out there ! self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/?y') ! self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/;x') self.checkJoin(RFC2396_BASE, 'g:h', 'g:h') self.checkJoin(RFC2396_BASE, 'g', 'http://a/b/c/g') ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-22 21:34 Message: Logged In: YES user_id=44345 added Aaron's RFC 2396 tests to test_urlparse.py version 1.4 - the two failing tests are commented out ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-03-18 06:22 Message: Logged In: YES user_id=76089 I think it would be better btw if '..' components taking you 'off the top' were stripped. RFC 2396 says this is valid behaviour, and it's what 'real' browsers do. i.e. http://a/b/ + ../../../d == http://a/d ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2001-11-05 10:34 Message: Logged In: YES user_id=122141 Oops, meant to attach it... ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2001-11-05 10:30 Message: Logged In: YES user_id=122141 Sure, here they are: import urlparse base = 'http://a/b/c/d;p?q' assert urlparse.urljoin(base, 'g:h') == 'g:h' assert urlparse.urljoin(base, 'g') == 'http://a/b/c/g' assert urlparse.urljoin(base, './g') == 'http://a/b/c/g' assert urlparse.urljoin(base, 'g/') == 'http://a/b/c/g/' assert urlparse.urljoin(base, '/g') == 'http://a/g' assert urlparse.urljoin(base, '//g') == 'http://g' assert urlparse.urljoin(base, '?y') == 'http://a/b/c/?y' assert urlparse.urljoin(base, 'g?y') == 'http://a/b/c/g?y' assert urlparse.urljoin(base, '#s') == 'http://a/b/c/ d;p?q#s' assert urlparse.urljoin(base, 'g#s') == 'http://a/b/c/g#s' assert urlparse.urljoin(base, 'g?y#s') == 'http://a/b/c/ g?y#s' assert urlparse.urljoin(base, ';x') == 'http://a/b/c/;x' assert urlparse.urljoin(base, 'g;x') == 'http://a/b/c/g;x' assert urlparse.urljoin(base, 'g;x?y#s') == 'http://a/b/c/ g;x?y#s' assert urlparse.urljoin(base, '.') == 'http://a/b/c/' assert urlparse.urljoin(base, './') == 'http://a/b/c/' assert urlparse.urljoin(base, '..') == 'http://a/b/' assert urlparse.urljoin(base, '../') == 'http://a/b/' assert urlparse.urljoin(base, '../g') == 'http://a/b/g' assert urlparse.urljoin(base, '../..') == 'http://a/' assert urlparse.urljoin(base, '../../') == 'http://a/' assert urlparse.urljoin(base, '../../g') == 'http://a/g' assert urlparse.urljoin(base, '') == base assert urlparse.urljoin(base, '../../../g') == 'http://a/../g' assert urlparse.urljoin(base, '../../../../g') == 'http://a/../../g' assert urlparse.urljoin(base, '/./g') == 'http://a/./g' assert urlparse.urljoin(base, '/../g') == 'http://a/../g' assert urlparse.urljoin(base, 'g.') == 'http://a/b/c/ g.' assert urlparse.urljoin(base, '.g') == 'http://a/b/c/ .g' assert urlparse.urljoin(base, 'g..') == 'http://a/b/c/ g..' assert urlparse.urljoin(base, '..g') == 'http://a/b/c/ ..g' assert urlparse.urljoin(base, './../g') == 'http://a/b/g' assert urlparse.urljoin(base, './g/.') == 'http://a/b/c/ g/' assert urlparse.urljoin(base, 'g/./h') == 'http://a/b/c/ g/h' assert urlparse.urljoin(base, 'g/../h') == 'http://a/b/c/ h' assert urlparse.urljoin(base, 'g;x=1/./y') == 'http://a/b/c/g;x=1/y' assert urlparse.urljoin(base, 'g;x=1/../y') == 'http://a/b/ c/y' assert urlparse.urljoin(base, 'g?y/./x') == 'http://a/b/c/g?y/./x' assert urlparse.urljoin(base, 'g?y/../x') == 'http://a/b/c/g?y/../x' assert urlparse.urljoin(base, 'g#s/./x') == 'http://a/b/ c/g#s/./x' assert urlparse.urljoin(base, 'g#s/../x') == 'http://a/b/ c/g#s/../x' ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-05 10:05 Message: Logged In: YES user_id=3066 This looks like its probably related to #478038; I'll try to tackle them together. Can you attach your tests to the bug report on SF? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470 From noreply@sourceforge.net Sat May 17 01:00:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 17:00:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-458447 ] New httplib lacks documentation Message-ID: Bugs item #458447, was opened at 2001-09-04 10:01 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=458447&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Fixed Priority: 6 Submitted By: Rich Salz (rsalz) >Assigned to: Brett Cannon (bcannon) Summary: New httplib lacks documentation Initial Comment: urllib should allow the user to set the content-type. This would allow applications to do more than just "forms posting" -- e.g., use it to make SOAP requests. The attached patch allows that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 23:36 Message: Logged In: YES user_id=357491 It looks like the parameters to HTTPSConnection have changed and are now ``def __init__(self, host, port=None, key_file=None, cert_file=None, strict=None):``. The docs on the key file and cert file can probably be copied from socket.ssl . ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-12-18 09:34 Message: Logged In: YES user_id=36737 The **x509 parameter of HTTPSConnection needs to be documented. It's a dictionary with at most two keys. key_file specifies the PEM-fformat private key file and cert_file specifies contains the PEM-format certificate and optional list of CA's in the cert chain. (I believe there's an open defect for SSL sockets not being docuemented.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-29 22:07 Message: Logged In: YES user_id=3066 Checked in as Doc/lib/libhttplib.tex revision 1.28. Updates contributed by Kalle Svensson. Thanks, Kalle! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-26 13:51 Message: Logged In: YES user_id=3066 I have contributed docs for the new version waiting for review in my inbox; these should be checked in this week. Bumping priority so this stays visible to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:37 Message: Logged In: YES user_id=6380 Fred: it turns out the httplib docs still document the old version of the module. The new version is considerably more powerful, and is essentially undocumented. Maybe you can shame Greg Stein into providing some docs, or maybe you can convert the copious docstrings to LaTeX. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-09-04 20:45 Message: Logged In: YES user_id=44345 I'm not sure why you'd want to program SOAP (or XMLRPC, for that matter) directly. You would (normally) only use those protocols through special-purpose modules like SOAP.py or xmlrpclib.py, both of which talk to httplib I believe. I don't see that allowing the Content-Type: header to be overridden at the urllib level is all that necessary. If you're going to want to mess with Content-Type: you're probably going to want to mess with other headers as well. ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-09-04 19:02 Message: Logged In: YES user_id=36737 I created this bug because urllib didn't let you set the content-type header. Guido pointed out that I should be using httplib. I didn't use httplib because I didn't know until I read the source, that httplib had an https object that used SSL. So I guess "document the https object" is what this has mutated into. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 14:03 Message: Logged In: YES user_id=3066 It's not at all clear what sort of documentation update is needed. What did you have in mind? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 12:20 Message: Logged In: YES user_id=6380 Please don't Delete requests. Please don't Close them unless you are a project manager (I consider it a SF bug that the submitter can decide to close a bug report if they happen to have admin perms on another project). I've reopened this and recategorized as Doc and assigned to Fred so he can see if the httplib docs need to be updated. ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-09-04 12:16 Message: Logged In: YES user_id=36737 Okay, I'll accept that. Had HTTP documented that it included HTTPS I wouldn't have made the initial mistake. :) Let me know if you want the diff. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:20 Message: Logged In: YES user_id=6380 Isn't SOAP an HTTP application? Then you shouldn't be using urllib, but httplib. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:20 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=458447&group_id=5470 From noreply@sourceforge.net Sat May 17 01:25:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 17:25:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-467384 ] provide a documented serialization func Message-ID: Bugs item #467384, was opened at 2001-10-02 19:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467384&group_id=5470 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: provide a documented serialization func Initial Comment: It would be nice if there was a documented library function for serializing Python basic objects (numbers, strings, dictionaries, and lists). By documented I mean the protocol is specified in the documentation, precisely enough to write interoperating implementations in other languages. Code-wise, the marshal.dumps and loads functions do what I want, but their data format is (according to the documentation) intentionally not specified, because the format might change in future Python versions. Maybe that doc was written long enough ago that it's ok to freeze the marshal format now, and document it? I just mean for the basic types listed above. Stuff like code objects don't have to be specified. In fact it would be nice if there was a flag to the loads and dumps functions to refuse to marshal/ unmarshal those objects. Pickle/cpickle aren't really appropriate for what I'm asking, since they're complicated (they try to handle class instances, circular structure, etc.) and anyway they're not documented either. The XDR library is sort of ok, but it's written in Python (i.e. slow) and it doesn't automatically handle compound objects. Thanks ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 17:25 Message: Logged In: YES user_id=357491 Is this still an issue? If so, shouldn't this be made an RFE? ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-16 16:28 Message: Logged In: YES user_id=72053 Tim has opened a doc bug for pickle/marshal security issues as #471893. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-14 15:27 Message: Logged In: YES user_id=72053 My understanding of marshal (I better check it, but I did mention the issue in the original request) is that it can create code objects but it doesn't actually execute the code in them. My implementation currently uses marshal but checks that the stuff marshal returns doesn't contain anything unexpected. Unpickle is different--it looks like it can execute hostile code before the loads call ever returns. By the time you have a chance to check the result, it's too late. cPickle.c appears to work exactly the same way (using eval and creating arbitrary instances, but maybe not calling marshal) as pickle.py. It never would have occured to me that the unpickler would work that way (and I'm still not convinced I understand it--I better try putting together a test to see if it's really like that). That's why I didn't notice the security issue til we started discussing pickle and I actually looked at the code. I'm sorry if that sounds like I'm adding requirements. I'd have thought it would go without saying that an important utility shouldn't have security holes. I'm ok with using pickle if the doc and security concerns are taken care of. More efficient longs would be helpful but they would break interoperability with old versions and I can probably live without them. It's really sad that longs were shrugged off when the pickle binary format was designed. Now in order to have efficient longs, yet another flag will have to be added to the constructor. Btw, if the unpickle security issue is real (I'm still not convinced!), I feel it should be treated as a major bug and that an announcement should be sent out. Unpickle already anticipates hostile pickled strings in the non-binary format and checks for them (see _is_secure_string) though I'd want want to spend an hour or two checking both the `...` code and the evaluator before believing that _is_secure_string is really safe-- and even if it is, it's brittle. But it looks like object creation security is an area they didn't think about. Basically I have nothing against pickle in principle, but it has these (fixable) problems, and while marshal is straightforwardly written, both pickle implementations are excessively clever and make me queasy. Anyway, I can go along with the idea that the right solution is to fix pickle--but at present, pickle looks like it's in worse shape than marshal. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-14 13:36 Message: Logged In: YES user_id=31435 Ack -- Paul, you add a new hitherto secret requirement with each reply. marshal isn't secure at all: because its *purpose* is to load .pyc files, marshal creates Python code objects out of any bytes you happen to feed it following a "code object" tag. That's a hole big enough to swallow the solar system. In 2.2, marshal refuses to unpack code objects in restricted execution mode, but not before 2.2, and it never refuses in unrestricted mode. In contrast, pickle doesn't know anything about code objects, so doesn't have this hole. The pickle docs are clear about this, too, spelling out that marshal's code- object abilities create "the possibility of smuggling Trojan horses into a program". When wondering about security, you should be looking at (and using) cPickle.c instead of pickle.py; cPickle doesn't use marshal at all, nor does it do eval()s etc. Yes, it can reconstruct pickled instances of classes that already exist, but it cannot create new classes. I haven't heard that characterized as an insecurity before, but to each his own level of discomfort. I want to go back to the start: if the question is whether Python is interested in documenting another data transmission format, my answer is no. There are many already (don't forget the ones from the CORBA and ILU worlds either) available from Python, and there's no reason to believe encoders/decoders for a Python-specific format would get implemented in any other language. pickle is Python's generic answer to the Python-specific serialization question. I'd be happy to see patches to improve it (whether for efficient longs, or some stricter notion of security, or even just docs). But I expect any additional Python-specific serialization scheme has an audience of one (if you disagree, fine, write a PEP and get some community consensus). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 17:49 Message: Logged In: YES user_id=72053 I agree with Tim that the internal implementation of long arithmetic isn't relevant to this--it was just surprising, and means the current marshal format isn't all that natural for external use. I don't have a particular agenda to get marshal documented, beyond that it would happen to solve my immediate problem. Alternatives are fine too. The ones suggested so far just don't seem to do the job, viz.: xmlrpc does NOT serialize basic Python objects--in particular it doesn't serialize integers longer than 32 bits. I can't consider using pickle until I've convinced myself that it doesn't make security holes, and so far it looks like the opposite. (Can someone tell me I'm not reading it right?). Yes, of course, it's not that difficult to write Python code to do everything I want. It's just surprising that I should need to do that. I mean, imagine if there was no integer addition function (no "+" operator) and the maintainers said "that's ok, to add a and b, just use 'a - (-b)'". It's not a showstopping obstacle, but I'm surprised to get so much grief for suggesting making the operation more convenient, since it's an obvious thing to want to do (as evidenced by there already being so many overlapping serialization functions: marshal, pickle, rpclib, the Serialization class from Vaults of Parnassus, three different ASN1 implementations you mentioned, etc). I can't see anywhere where I've requested a "special gimmick". Yes, an efficient bigint representation in pickle is nice and ought to be added, but I can live without it. I can NOT live with security holes, but wanting security shouldn't be considered a special gimmick! With binary bigints, a documented format, and a way to 100% stop the unpickler from ever calling eval or apply on untrusted data, I wouldn't mind using pickle despite its additional complexity compared to marshal. I don't want to depend on third party modules unless I bundle them with my application (again not a showstopper, but it's not in Python's "batteries included" spirit to need them at all). Telling a user "to run this app, first download modules vreeble from and frob from " where url1 and url2 usually turn out to be broken links by the time the user sees them is not the right way to distribute an app. (It happens I'm going to sometimes tell the user "to run this app, first destroy your handheld computer's OS by reflashing the firmware..." but it's the principle of the thing, you know). Anyway, the 15 bit bigint representation is reason enough to not want to freeze the current marshal format. Maybe a future marshaller can use a cleaner bigint format and at that point perhaps the issue can be revisited. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 16:29 Message: Logged In: YES user_id=72053 A pickle subset ("gherkin"?) could possibly also fill this need, if it was documented, even though pickle format is considerably more complicated than marshal format (it uses marshal.dumps for binary output, actually taking apart the marshalled strings). It was obvious in seconds how marshal.c works but after 30 minutes of looking at pickle.py I'm still not sure I understand it. It looks like the unpickler can construct arbitrary class instances and import arbitrary modules, which makes a security hole if the pickled strings are potentially hostile, but I might not be reading it right. Also, the unpickler must implement constant folding (the memo scheme), which complicates it somewhat, though it's not that bad. The idea of leaving the marshal formats of some Python- specific objects undocumented isn't to get out of documenting stuff, but to leave those formats open to later change. Re BER/DER, Burt Kaliski's "Layman's Guide" is pretty readable (http://borg.isc.ucsb.edu/aka/Auth/ASN1layman.htm). You're right about using all 8 bits in BER integers--it looks like the 7 bit representation is only used for OID components (I didn't realize that til checking on it just now). BER might be ok for what I'm doing--I'm not sure right now since I don't understand ASN1 that well. It looks not in the spirit of marshal/pickle though: to encode a compound object it looks like you need an ASN1 spec of EXACTLY what you expect to find in the object. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 15:25 Message: Logged In: YES user_id=31435 Martin, you're right about add and sub, but it's a shallow assumption easy to relax (basically just declare carry/borrow as twodigits instead of digit). I'd be more worried about the stwodigits type, but since nothing is actually broken here I'm not keen to fritter away time proving bounds on the temps in bigint division. How we implement bigints internally is off topic anyway (provided we're not trying to hijack internal implementation formats for unintended purposes). About BER, yes, and the URL I included is to a freely downloadable copy of the X.690 std; section 8.3 spells out the INTEGER rules. They aren't at all the rules Paul sketched, hence "I don't really know what you [Paul] mean by 'BER'". For the rest, while xmlrcplib may meet the letter of what Paul asked for at first, it's clear to me that it doesn't meet what he really wants. My suggestion remains to add a new, efficient bigint format to pickle, which would meet everything except Paul's desire to have a special gimmick limited to his specific application and without having to write one himself. The internal API functions _PyLong_AsByteArray and _PyLong_FromByteArray already do the heavy lifting in both directions (to or from base 256, unsigned or complemented, big- or little-endian). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-13 14:04 Message: Logged In: YES user_id=21627 7-bit vs. 8-bit: You were confusing tag encoding and INTEGER value encoding. no way to encode a string with a length: suppose you want a 32 bit length, what's wrong with struct.pack("l",len(s))+s 15-bit representation: I believe the add and sub implementations make use of the guarantee that a short won't overflow if the input fits into 15 bits. Tim: BER = Basic Encoding Rules (as in the subtitle of X.690) Even after all this discussion, I still cannot see why the existing libraries (including those offered for free by third parties) are not sufficient. It appears that Paul wants, among other things, that marshal becomes documented; it also appears that this won't hapen. What the other things are that Paul wants, I cannot tell, so I recommend to close this report with "won't fix". Paul, if you have a specific change that you want to be made, or a specific problem that you want to point out, please submit a new report. This issue "provide a documented serialization func" really ought to be closed as "Fixed"; xmlrpclib is already part of standard library and fits the original problem description: - it is a library for serializing Python basic objects - it is documented in the sense that the protocol is specified precisely enough to write interoperating implementations in other languages. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 12:07 Message: Logged In: YES user_id=31435 I don't buy the argument that pickle is "complicated", as you weren't going to document the parts of the marshal format you didn't care about either. A subset of pickle is just as easy to document and implement across languages as a subset of marshal, but with the key benefit that the pickle format is stable across releases. So if you want a structure packer, pickle is the obvious choice; it just lacks an efficient (in time and space) scheme for storing longs now. And unlike marshal, it isn't a dead end when you decide your app needs something fancier -- pickle already handles just about everything that *can* be pickled, and is designed to be extensible to user-defined types too, so you can painlessly expand your view of what the "interesting" subset is as your ambitions grow. I don't really know what you mean by "BER". The ANS.1 std section 8.3 is quite clear that all 8 bits are used in each byte for integer representations -- it's a giant 2's-comp integer, with a variable-length length prefix, redundant sign bytes are forbidden, and there's nothing special about the last byte. I agree with Martin that ANS.1 BER is as compact a standardized bigint representation as there is. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 03:24 Message: Logged In: YES user_id=72053 1) if Python longs are currently implemented as vectors of 15-bit digits (yikes--why on earth would anyone do that) and marshalled like that, then I agree that THAT much weirdness doesn't need to be propagated to future versions. Wow! I never looked at the long int code closely, but the marshal code certainly didn't reflect that. It's still possible to freeze the current marshal format and let future versions define a new mechanism for loading .pyc's. >From my own self-interest (of wanting to distribute apps that work across versions) that idea attracts me, but it's probably not the right thing in the long run. Better may be to fix the long int format right away and THEN document/ freeze it. (Use a new format byte so the 2.2 demarshaller can still read 2.1 .pyc files). By "fix" I mean use a simple packed binary format, no 15 bit digits, no BER, and the length prefix should be a byte or bit count, not multibyte "digits". 2) Unfortunately it's not easy in portable C with 32 bit longs to use digits wider than 16 bits--multiplication becomes too complicated. If the compiler supports wide ints (long long int) then conditionalized code to use them might or might not be deemed worthwhile. Python's long int arithmetic (unlike Perl's Math::BigInt class) is fast enough to be useable for real applications and I don't expect it to go to the extremes that gmpy does (highly tuned algorithms for everything, asm code for many cpu's, etc). So currently I use gmpy when it's available and fall back on longs if gmpy won't import--this works pretty well so far. 3) I like the idea of a BER/DER library for Python but I don't feel like being the guy who writes it. I'd probably use it if it was available, though maybe not for this purpose. (I'd like to handle X509 certificates in Python). BER really isn't the most efficient way to store long ints, by the way, since it puts just 7 useful bits in a byte. 4) My suggestion of BER in 465045 was motivated slightly differently, which was to add a feature from Perl's pack/ unpack function that's missing from Python's struct.pack/ unpack. I understand a little better now what the struct module is for, so binascii may be a better place for such a thing. However, I believe Python really needs a pack/unpack module that does all the stuff that Perl's does. Data conversion like that is an area where Perl is still beating Python pretty badly. (Again, I don't feel like being the one who writes the module). 5) Sorry I didn't notice Guido's post of 20:24 earlier (several arrived at once). I guess I'm willing to submit a patch for binascii to read and write longs in binary. It's slightly humorous to put it in binascii since it's a binary-binary conversion with no ascii involved, but the function fits well there in any case. I'd still rather use marshal, since I want to write out more kinds of data than longs, and with a long->binary conversion function I'd still need to supply Python code to traverse dictionaries and lists, and encode strings. Btw, the struct module doesn't have any way to encode strings with a length, except the Pascal format which is limited to 256 bytes and is therefore useless for many things. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 01:39 Message: Logged In: YES user_id=31435 Martin, Paul suggested BER previously in 465045. I suspect he's going to suggest this for every module one by one, until somebody bites . I doubt he wants genuine ASN.1 BER, though, as that's a complicated beast, and he only cares about ints with a measly few hundred bits; regardless, a Python long can't have more digits than can be counted in a C int. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-13 01:14 Message: Logged In: YES user_id=21627 I would have never guessed that arbitrarily long ints are a requirement in your application... For that application, I'd recommend to use ASN.1 BER as a well-document, efficient, binary marshalling format. I don't think any other format marshals arbitrary large integers in a more compact form. You can find an implementation of that in http://www.cnri.reston.va.us/software/pisces/ or http://www.enteract.com/~asl2/software/PyZ3950/asn1.py or http://sourceforge.net/projects/pysnmp (ber.py) I'd be in favour of having a BER support library in the Python core, but somebody would have to contribute such a thing, of course. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-12 20:43 Message: Logged In: YES user_id=31435 The marshal long format actually uses 15-bit digits, each *stored* in 16 bits (the high bit of the high byte of which is always 0). That would be a PITA to preserve even if Python just moved to 16-bit digits. marshal's purpose is for efficient loading of .pyc files, where that odd format makes good sense; since it wasn't designed to be a general- purpose data transmission format (and has many shortcomings for such use), I don't want to see a tail wagging the dog here. Cross-release compatibility is taken seriously in pickle, and pickle handles many more cases than marshal, although pickle's author (as you've discovered) didn't give a hoot about efficient storage of longs. I'd rather add an efficient long format to pickle than hobble marshal (although because pickle does take x-release compatibility seriously, it has to continue accepting the "longs as decimal strings" format forever). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 20:08 Message: Logged In: YES user_id=72053 Skip - C has struct objects which are sort of like Python dictionaries. XMLRPC represents structs as name-value pairs, for example. And "other languages" doesn't necessarily mean C. The marshaller should be able to represent the non-Python-specific serializable objects, not just scalars. Basically this means strings, integers (of any length), dictionaries, lists, and floats (hmm--unicode?), but not necessarily stuff like code objects. Having an independent marshal library is ok, I guess, though I don't feel it's necessary to create more implementation work. And one the benefit of using the existing marshaller is that it's already available in most versions of Python that people are running (Red Hat 7.1 still comes with Python 1.5 for example). Tim - yes, I'm originally used a binascii.hexlify hack similar to yours and it worked ok, but it was ugly. I also had to handle strings (generate a length count followed by the contents) and then dictionaries (name-value pairs) and finally felt I shouldn't need to rewrite the marshaller like that. There's already a built-in library function that does everything I need, very efficiently in native code, in one call, and being able to use it is in the "batteries included" spirit. Also, the current long int marshalling format is just a digit count (16-bit digits) followed by the digits in binary. If the digit width changes, the marshalling format doesn't have to change--the marshalling code should still be able to use the same external representation without excessive contortions and without slowing down. (You'll see that it's already not a simple memory dump, but a structure read and written one byte at a time through layers of subroutines). Changing widths while keeping the old format means putting a minor kludge in the marshalling code, but no user will ever notice it. As for the speed of Python longs, my stuff's runtime is dominated by modular exponentiations and I'm already using gmpy for those when it's available (but I don't depend on it). The speedup with gmpy is substantial, but the speed with ordinary Python longs is quite acceptable on my PIII (the StrongARM is another story--probably the C compiler's fault). Examining Python/marshal.c, I don't see any objects of the types I've mentioned that are likely to need to change representations--do you? Btw I notice that the pickle module represents long ints as decimal strings even in "binary" mode, but I'll resist opening another bug for that, for now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-12 14:41 Message: Logged In: YES user_id=44345 If you head in the direction of documenting marshal with the aim of potentially interoperating with other languages, I think it would be a good idea to create a Python-independent marshal library. This would facilitate incorporation into other languages. Such a library probably wouldn't be able to do everything marshal can (there isn't an obvious C equivalent of Python's dictionary object, for example), but would still help nail down compatibility issues for the basic scalar types. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-12 14:09 Message: Logged In: YES user_id=31435 I'm not sure this is making progress. Paul, if you want to use marshal, you already can: the pack and unpack routines are exposed in Python via the marshal module. Freezing the representation isn't a particularly appealing idea; e.g., if anyone is likely to complain about the speed of Python's longs, it's you , and the current marshal format for longs is just a raw dump of Python's internal long representation -- but the most obvious everything-benefits way to speed Python longs is to increase the size of the "digits" used in its internal representation. If that's ever done, the marshal format would want to change too. It's easy enough to code your own storage format for longs, e.g. >>> def tobin(i): ... import binascii ... ashex = hex(long(i))[2:-1] # chop '0x' and trailing 'L' ... if len(ashex) & 1: ... ashex = '0' + ashex ... return binascii.unhexlify(ashex) implements "base 256" for unsigned longs, and the runtime cannot be improved by rewriting in C except by a constant factor (the Python spelling has the right O() behavior). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 13:24 Message: Logged In: YES user_id=6380 This helps tremendously. I think that marshal is probably overkill. Rather, you need helper routines to convert longs to and from binary. You can do everything else using the struct module, and it's probably easier to write your own protocol using that and these helpers. I suggest that the best place to add these helpers is the binascii module, which already has a bunch of similar things (e.g. hexlify and crc32). Note the xmlrpc is bundled with Python 2.2. Looking forward to your patch (much simpler to get accepted than a PEP :-). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 13:16 Message: Logged In: YES user_id=72053 Decimal is bad not just because of the data expansion but because the arithmetic to convert a decimal string to binary can be expensive (all that multiplication). I'd rather use hex than decimal for that reason. One envisioned application is communicating a cryptography coprocessor: an 8-bit microcontroller (with a public key accelerator) connected to the host computer through a slow serial port. Most of the ints involved would be around 300 decimal digits. A simple binary format is a lot easier to deal with in that environment than something like xmlrpc. Also, the format would be used for data persistence, so again, unnecessary data expansion isn't desirable. I looked at XMLRPC and it's not designed for this purpose. It's intended as an RPC protocol over HTTP and isn't well suited for object persistence. Also, it doesn't support integers over 32 bits, and binary strings must be base64 encoded (more bloat). Finally, it's not included with Python, so I'd have to bundle an implementation written in Python (i.e. slow) with my application (I don't know whether Fred's implementation is Python or C). I think the marshal format hasn't changed since before Python 1.5, so basing serialization on marshal would mean applications could interoperate with older versions of Python as well as newer ones, which helps Python's maturity. (Maturity of a program means, among other things, that users rarely need to be told they need the latest version in order to use some feature). Really, the marshal functions are written the way they're written because that's the simplest and most natural way of doing this kind of thing. So the proposal is mainly to make them available for user applications, rather than only for system internals. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 12:37 Message: Logged In: YES user_id=6380 If the PEP makes a reasonable case for freezing the spec, yes. I wonder why you can't use decimal? Are you talking really large volumes? The PEP needs to motivate this with an example, preferably plucked from real life! ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 12:29 Message: Logged In: YES user_id=72053 I just want to be able to do convenient transfers of python data to other programs including over the network. XMLRPC is excessive bloat in my opinion. Sending a number like 12345678 should take at most 5 bytes (a type byte and a 4-byte int) instead of 12345678. For long ints (300 digits) it's even worse. The marshal format is fine, and writing a PEP would solve the doc problem, but the current marshal doc says the non-specification is intentional. Writing it in a PEP means not just documenting--it means asking the language maintainers to freeze the marshal format of certain types, instead of reserving the right to change the format in future versions. Writing the PEP only makes sense if you're willing to freeze the format for those types (the other types can stay undocumented). Is that ok with you? Thanks Paul ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 07:33 Message: Logged In: YES user_id=6380 Paul, I don't understand the application that you are envisioning. If you think that the marshal format is what you want, why don't you write a PEP that specifies the format? That would solve the documentation problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-12 02:39 Message: Logged In: YES user_id=21627 Well, then I guess you need to specify your requirements more clearly. XML-RPC was precisely developed to be something simple for primitive types and structures that is sufficiently well-specified to allow interoperation between various languages. I don't see why extending the data 'by an order of magnitude' would be a problem per se, nor do I see why 'requiring a complicated parser' is a problem if the implementation already does all the unpacking for you under the hoods. Furthermore, I believe it is simply not true that XML-RPC expands the representation by an order of magnitude. For example, the Python Integer object 1 takes 12 bytes in its internal representation (plus the overhead that malloc requires); the XML-RPC representation '1' also uses 12 bytes. In short, you need to say as precise as possible what it is that you want, or you won't get it. Also, it may be that you have conflicting requirements (e.g. 'compact, binary', and 'simple, easily processible in different languages'); then you won't get it either. For a marshalling format that is accessible from different languages, you better specify it first, and implement it then. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 22:12 Message: Logged In: YES user_id=72053 I haven't looked at xmlrpclib, but I'm looking for a simple, compact, binary representation, not something that needs a complicated parser and expands the data by an order of magnitude. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-05 17:10 Message: Logged In: YES user_id=21627 So what's wrong with xmlrpclib? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467384&group_id=5470 From noreply@sourceforge.net Sat May 17 01:54:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 17:54:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-515137 ] metaclasses and 2.2 highlights Message-ID: Bugs item #515137, was opened at 2002-02-08 22:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=515137&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: paul rubin (phr) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: metaclasses and 2.2 highlights Initial Comment: The 2.2 highlights list at python.org doesn't mention metaclasses. Maybe they're considered part of the type/class unification but I didn't notice them til reading some old c.l.py articles about class design. I think they're an important enough addition that they should be mentioned in the highlights. --phr ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 17:54 Message: Logged In: YES user_id=357491 Closing this and rejecting it since things about web pages should be sent to webmaster@python.org and not here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=515137&group_id=5470 From noreply@sourceforge.net Sat May 17 01:58:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 17:58:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-522780 ] bsddb keys corruption Message-ID: Bugs item #522780, was opened at 2002-02-25 18:49 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=522780&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Marc Conley (mconley) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb keys corruption Initial Comment: I'm having a problem with either the keys() function returning invalid information or the database getting corrupted or something along those lines. This is what I keep seeing occasionally during my development: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> db = bsddb.hashopen("test.db") >>> db.keys() ['192.168.0.1799'] >>> db["192.168.0.1799"] Traceback (most recent call last): File "", line 1, in ? KeyError: 192.168.0.1799 >>> The lines of importance are the return value for db.keys() and then the traceback. Note that the db.keys () returns a value that I immediately try to access and get a KeyError in so doing. This happens in a program with multiple threads but for which I am using a threading.Lock acquire() and release() around all database/bsddb accesses. I am also using sync()s after all write operations. The key value, by the way, should be 192.168.0.179. It is consistently, on several different occasions, getting the extra "9" appended to the end of it. This same problem has occurred 3 times during testing. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 17:58 Message: Logged In: YES user_id=357491 Well, considering no one has provided a test case to reproduce this in over half a year I am closing this bug as invalid. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-06 10:09 Message: Logged In: YES user_id=7887 Marc, could you please provide a testcase, as stated below? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-10 04:42 Message: Logged In: YES user_id=539787 What does the following produce as output in the above example? >>> db[db.keys()[0]] If that fails, you most surely have key corruption. If not, then please come back with a standalone script that displays erratic behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=522780&group_id=5470 From noreply@sourceforge.net Sat May 17 02:17:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:17:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-467384 ] provide a documented serialization func Message-ID: Bugs item #467384, was opened at 2001-10-03 02:25 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467384&group_id=5470 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: provide a documented serialization func Initial Comment: It would be nice if there was a documented library function for serializing Python basic objects (numbers, strings, dictionaries, and lists). By documented I mean the protocol is specified in the documentation, precisely enough to write interoperating implementations in other languages. Code-wise, the marshal.dumps and loads functions do what I want, but their data format is (according to the documentation) intentionally not specified, because the format might change in future Python versions. Maybe that doc was written long enough ago that it's ok to freeze the marshal format now, and document it? I just mean for the basic types listed above. Stuff like code objects don't have to be specified. In fact it would be nice if there was a flag to the loads and dumps functions to refuse to marshal/ unmarshal those objects. Pickle/cpickle aren't really appropriate for what I'm asking, since they're complicated (they try to handle class instances, circular structure, etc.) and anyway they're not documented either. The XDR library is sort of ok, but it's written in Python (i.e. slow) and it doesn't automatically handle compound objects. Thanks ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2003-05-17 01:17 Message: Logged In: YES user_id=72053 Yes, it's still an issue, even more than before since pickle is now explicitly documented to NOT be ok to use with untrusted data. This is already classified as a feature request. I don't know if an RFE is something different than that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 00:25 Message: Logged In: YES user_id=357491 Is this still an issue? If so, shouldn't this be made an RFE? ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-16 23:28 Message: Logged In: YES user_id=72053 Tim has opened a doc bug for pickle/marshal security issues as #471893. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-14 22:27 Message: Logged In: YES user_id=72053 My understanding of marshal (I better check it, but I did mention the issue in the original request) is that it can create code objects but it doesn't actually execute the code in them. My implementation currently uses marshal but checks that the stuff marshal returns doesn't contain anything unexpected. Unpickle is different--it looks like it can execute hostile code before the loads call ever returns. By the time you have a chance to check the result, it's too late. cPickle.c appears to work exactly the same way (using eval and creating arbitrary instances, but maybe not calling marshal) as pickle.py. It never would have occured to me that the unpickler would work that way (and I'm still not convinced I understand it--I better try putting together a test to see if it's really like that). That's why I didn't notice the security issue til we started discussing pickle and I actually looked at the code. I'm sorry if that sounds like I'm adding requirements. I'd have thought it would go without saying that an important utility shouldn't have security holes. I'm ok with using pickle if the doc and security concerns are taken care of. More efficient longs would be helpful but they would break interoperability with old versions and I can probably live without them. It's really sad that longs were shrugged off when the pickle binary format was designed. Now in order to have efficient longs, yet another flag will have to be added to the constructor. Btw, if the unpickle security issue is real (I'm still not convinced!), I feel it should be treated as a major bug and that an announcement should be sent out. Unpickle already anticipates hostile pickled strings in the non-binary format and checks for them (see _is_secure_string) though I'd want want to spend an hour or two checking both the `...` code and the evaluator before believing that _is_secure_string is really safe-- and even if it is, it's brittle. But it looks like object creation security is an area they didn't think about. Basically I have nothing against pickle in principle, but it has these (fixable) problems, and while marshal is straightforwardly written, both pickle implementations are excessively clever and make me queasy. Anyway, I can go along with the idea that the right solution is to fix pickle--but at present, pickle looks like it's in worse shape than marshal. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-14 20:36 Message: Logged In: YES user_id=31435 Ack -- Paul, you add a new hitherto secret requirement with each reply. marshal isn't secure at all: because its *purpose* is to load .pyc files, marshal creates Python code objects out of any bytes you happen to feed it following a "code object" tag. That's a hole big enough to swallow the solar system. In 2.2, marshal refuses to unpack code objects in restricted execution mode, but not before 2.2, and it never refuses in unrestricted mode. In contrast, pickle doesn't know anything about code objects, so doesn't have this hole. The pickle docs are clear about this, too, spelling out that marshal's code- object abilities create "the possibility of smuggling Trojan horses into a program". When wondering about security, you should be looking at (and using) cPickle.c instead of pickle.py; cPickle doesn't use marshal at all, nor does it do eval()s etc. Yes, it can reconstruct pickled instances of classes that already exist, but it cannot create new classes. I haven't heard that characterized as an insecurity before, but to each his own level of discomfort. I want to go back to the start: if the question is whether Python is interested in documenting another data transmission format, my answer is no. There are many already (don't forget the ones from the CORBA and ILU worlds either) available from Python, and there's no reason to believe encoders/decoders for a Python-specific format would get implemented in any other language. pickle is Python's generic answer to the Python-specific serialization question. I'd be happy to see patches to improve it (whether for efficient longs, or some stricter notion of security, or even just docs). But I expect any additional Python-specific serialization scheme has an audience of one (if you disagree, fine, write a PEP and get some community consensus). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-14 00:49 Message: Logged In: YES user_id=72053 I agree with Tim that the internal implementation of long arithmetic isn't relevant to this--it was just surprising, and means the current marshal format isn't all that natural for external use. I don't have a particular agenda to get marshal documented, beyond that it would happen to solve my immediate problem. Alternatives are fine too. The ones suggested so far just don't seem to do the job, viz.: xmlrpc does NOT serialize basic Python objects--in particular it doesn't serialize integers longer than 32 bits. I can't consider using pickle until I've convinced myself that it doesn't make security holes, and so far it looks like the opposite. (Can someone tell me I'm not reading it right?). Yes, of course, it's not that difficult to write Python code to do everything I want. It's just surprising that I should need to do that. I mean, imagine if there was no integer addition function (no "+" operator) and the maintainers said "that's ok, to add a and b, just use 'a - (-b)'". It's not a showstopping obstacle, but I'm surprised to get so much grief for suggesting making the operation more convenient, since it's an obvious thing to want to do (as evidenced by there already being so many overlapping serialization functions: marshal, pickle, rpclib, the Serialization class from Vaults of Parnassus, three different ASN1 implementations you mentioned, etc). I can't see anywhere where I've requested a "special gimmick". Yes, an efficient bigint representation in pickle is nice and ought to be added, but I can live without it. I can NOT live with security holes, but wanting security shouldn't be considered a special gimmick! With binary bigints, a documented format, and a way to 100% stop the unpickler from ever calling eval or apply on untrusted data, I wouldn't mind using pickle despite its additional complexity compared to marshal. I don't want to depend on third party modules unless I bundle them with my application (again not a showstopper, but it's not in Python's "batteries included" spirit to need them at all). Telling a user "to run this app, first download modules vreeble from and frob from " where url1 and url2 usually turn out to be broken links by the time the user sees them is not the right way to distribute an app. (It happens I'm going to sometimes tell the user "to run this app, first destroy your handheld computer's OS by reflashing the firmware..." but it's the principle of the thing, you know). Anyway, the 15 bit bigint representation is reason enough to not want to freeze the current marshal format. Maybe a future marshaller can use a cleaner bigint format and at that point perhaps the issue can be revisited. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 23:29 Message: Logged In: YES user_id=72053 A pickle subset ("gherkin"?) could possibly also fill this need, if it was documented, even though pickle format is considerably more complicated than marshal format (it uses marshal.dumps for binary output, actually taking apart the marshalled strings). It was obvious in seconds how marshal.c works but after 30 minutes of looking at pickle.py I'm still not sure I understand it. It looks like the unpickler can construct arbitrary class instances and import arbitrary modules, which makes a security hole if the pickled strings are potentially hostile, but I might not be reading it right. Also, the unpickler must implement constant folding (the memo scheme), which complicates it somewhat, though it's not that bad. The idea of leaving the marshal formats of some Python- specific objects undocumented isn't to get out of documenting stuff, but to leave those formats open to later change. Re BER/DER, Burt Kaliski's "Layman's Guide" is pretty readable (http://borg.isc.ucsb.edu/aka/Auth/ASN1layman.htm). You're right about using all 8 bits in BER integers--it looks like the 7 bit representation is only used for OID components (I didn't realize that til checking on it just now). BER might be ok for what I'm doing--I'm not sure right now since I don't understand ASN1 that well. It looks not in the spirit of marshal/pickle though: to encode a compound object it looks like you need an ASN1 spec of EXACTLY what you expect to find in the object. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 22:25 Message: Logged In: YES user_id=31435 Martin, you're right about add and sub, but it's a shallow assumption easy to relax (basically just declare carry/borrow as twodigits instead of digit). I'd be more worried about the stwodigits type, but since nothing is actually broken here I'm not keen to fritter away time proving bounds on the temps in bigint division. How we implement bigints internally is off topic anyway (provided we're not trying to hijack internal implementation formats for unintended purposes). About BER, yes, and the URL I included is to a freely downloadable copy of the X.690 std; section 8.3 spells out the INTEGER rules. They aren't at all the rules Paul sketched, hence "I don't really know what you [Paul] mean by 'BER'". For the rest, while xmlrcplib may meet the letter of what Paul asked for at first, it's clear to me that it doesn't meet what he really wants. My suggestion remains to add a new, efficient bigint format to pickle, which would meet everything except Paul's desire to have a special gimmick limited to his specific application and without having to write one himself. The internal API functions _PyLong_AsByteArray and _PyLong_FromByteArray already do the heavy lifting in both directions (to or from base 256, unsigned or complemented, big- or little-endian). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-13 21:04 Message: Logged In: YES user_id=21627 7-bit vs. 8-bit: You were confusing tag encoding and INTEGER value encoding. no way to encode a string with a length: suppose you want a 32 bit length, what's wrong with struct.pack("l",len(s))+s 15-bit representation: I believe the add and sub implementations make use of the guarantee that a short won't overflow if the input fits into 15 bits. Tim: BER = Basic Encoding Rules (as in the subtitle of X.690) Even after all this discussion, I still cannot see why the existing libraries (including those offered for free by third parties) are not sufficient. It appears that Paul wants, among other things, that marshal becomes documented; it also appears that this won't hapen. What the other things are that Paul wants, I cannot tell, so I recommend to close this report with "won't fix". Paul, if you have a specific change that you want to be made, or a specific problem that you want to point out, please submit a new report. This issue "provide a documented serialization func" really ought to be closed as "Fixed"; xmlrpclib is already part of standard library and fits the original problem description: - it is a library for serializing Python basic objects - it is documented in the sense that the protocol is specified precisely enough to write interoperating implementations in other languages. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 19:07 Message: Logged In: YES user_id=31435 I don't buy the argument that pickle is "complicated", as you weren't going to document the parts of the marshal format you didn't care about either. A subset of pickle is just as easy to document and implement across languages as a subset of marshal, but with the key benefit that the pickle format is stable across releases. So if you want a structure packer, pickle is the obvious choice; it just lacks an efficient (in time and space) scheme for storing longs now. And unlike marshal, it isn't a dead end when you decide your app needs something fancier -- pickle already handles just about everything that *can* be pickled, and is designed to be extensible to user-defined types too, so you can painlessly expand your view of what the "interesting" subset is as your ambitions grow. I don't really know what you mean by "BER". The ANS.1 std section 8.3 is quite clear that all 8 bits are used in each byte for integer representations -- it's a giant 2's-comp integer, with a variable-length length prefix, redundant sign bytes are forbidden, and there's nothing special about the last byte. I agree with Martin that ANS.1 BER is as compact a standardized bigint representation as there is. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 10:24 Message: Logged In: YES user_id=72053 1) if Python longs are currently implemented as vectors of 15-bit digits (yikes--why on earth would anyone do that) and marshalled like that, then I agree that THAT much weirdness doesn't need to be propagated to future versions. Wow! I never looked at the long int code closely, but the marshal code certainly didn't reflect that. It's still possible to freeze the current marshal format and let future versions define a new mechanism for loading .pyc's. >From my own self-interest (of wanting to distribute apps that work across versions) that idea attracts me, but it's probably not the right thing in the long run. Better may be to fix the long int format right away and THEN document/ freeze it. (Use a new format byte so the 2.2 demarshaller can still read 2.1 .pyc files). By "fix" I mean use a simple packed binary format, no 15 bit digits, no BER, and the length prefix should be a byte or bit count, not multibyte "digits". 2) Unfortunately it's not easy in portable C with 32 bit longs to use digits wider than 16 bits--multiplication becomes too complicated. If the compiler supports wide ints (long long int) then conditionalized code to use them might or might not be deemed worthwhile. Python's long int arithmetic (unlike Perl's Math::BigInt class) is fast enough to be useable for real applications and I don't expect it to go to the extremes that gmpy does (highly tuned algorithms for everything, asm code for many cpu's, etc). So currently I use gmpy when it's available and fall back on longs if gmpy won't import--this works pretty well so far. 3) I like the idea of a BER/DER library for Python but I don't feel like being the guy who writes it. I'd probably use it if it was available, though maybe not for this purpose. (I'd like to handle X509 certificates in Python). BER really isn't the most efficient way to store long ints, by the way, since it puts just 7 useful bits in a byte. 4) My suggestion of BER in 465045 was motivated slightly differently, which was to add a feature from Perl's pack/ unpack function that's missing from Python's struct.pack/ unpack. I understand a little better now what the struct module is for, so binascii may be a better place for such a thing. However, I believe Python really needs a pack/unpack module that does all the stuff that Perl's does. Data conversion like that is an area where Perl is still beating Python pretty badly. (Again, I don't feel like being the one who writes the module). 5) Sorry I didn't notice Guido's post of 20:24 earlier (several arrived at once). I guess I'm willing to submit a patch for binascii to read and write longs in binary. It's slightly humorous to put it in binascii since it's a binary-binary conversion with no ascii involved, but the function fits well there in any case. I'd still rather use marshal, since I want to write out more kinds of data than longs, and with a long->binary conversion function I'd still need to supply Python code to traverse dictionaries and lists, and encode strings. Btw, the struct module doesn't have any way to encode strings with a length, except the Pascal format which is limited to 256 bytes and is therefore useless for many things. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 08:39 Message: Logged In: YES user_id=31435 Martin, Paul suggested BER previously in 465045. I suspect he's going to suggest this for every module one by one, until somebody bites . I doubt he wants genuine ASN.1 BER, though, as that's a complicated beast, and he only cares about ints with a measly few hundred bits; regardless, a Python long can't have more digits than can be counted in a C int. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-13 08:14 Message: Logged In: YES user_id=21627 I would have never guessed that arbitrarily long ints are a requirement in your application... For that application, I'd recommend to use ASN.1 BER as a well-document, efficient, binary marshalling format. I don't think any other format marshals arbitrary large integers in a more compact form. You can find an implementation of that in http://www.cnri.reston.va.us/software/pisces/ or http://www.enteract.com/~asl2/software/PyZ3950/asn1.py or http://sourceforge.net/projects/pysnmp (ber.py) I'd be in favour of having a BER support library in the Python core, but somebody would have to contribute such a thing, of course. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 03:43 Message: Logged In: YES user_id=31435 The marshal long format actually uses 15-bit digits, each *stored* in 16 bits (the high bit of the high byte of which is always 0). That would be a PITA to preserve even if Python just moved to 16-bit digits. marshal's purpose is for efficient loading of .pyc files, where that odd format makes good sense; since it wasn't designed to be a general- purpose data transmission format (and has many shortcomings for such use), I don't want to see a tail wagging the dog here. Cross-release compatibility is taken seriously in pickle, and pickle handles many more cases than marshal, although pickle's author (as you've discovered) didn't give a hoot about efficient storage of longs. I'd rather add an efficient long format to pickle than hobble marshal (although because pickle does take x-release compatibility seriously, it has to continue accepting the "longs as decimal strings" format forever). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 03:08 Message: Logged In: YES user_id=72053 Skip - C has struct objects which are sort of like Python dictionaries. XMLRPC represents structs as name-value pairs, for example. And "other languages" doesn't necessarily mean C. The marshaller should be able to represent the non-Python-specific serializable objects, not just scalars. Basically this means strings, integers (of any length), dictionaries, lists, and floats (hmm--unicode?), but not necessarily stuff like code objects. Having an independent marshal library is ok, I guess, though I don't feel it's necessary to create more implementation work. And one the benefit of using the existing marshaller is that it's already available in most versions of Python that people are running (Red Hat 7.1 still comes with Python 1.5 for example). Tim - yes, I'm originally used a binascii.hexlify hack similar to yours and it worked ok, but it was ugly. I also had to handle strings (generate a length count followed by the contents) and then dictionaries (name-value pairs) and finally felt I shouldn't need to rewrite the marshaller like that. There's already a built-in library function that does everything I need, very efficiently in native code, in one call, and being able to use it is in the "batteries included" spirit. Also, the current long int marshalling format is just a digit count (16-bit digits) followed by the digits in binary. If the digit width changes, the marshalling format doesn't have to change--the marshalling code should still be able to use the same external representation without excessive contortions and without slowing down. (You'll see that it's already not a simple memory dump, but a structure read and written one byte at a time through layers of subroutines). Changing widths while keeping the old format means putting a minor kludge in the marshalling code, but no user will ever notice it. As for the speed of Python longs, my stuff's runtime is dominated by modular exponentiations and I'm already using gmpy for those when it's available (but I don't depend on it). The speedup with gmpy is substantial, but the speed with ordinary Python longs is quite acceptable on my PIII (the StrongARM is another story--probably the C compiler's fault). Examining Python/marshal.c, I don't see any objects of the types I've mentioned that are likely to need to change representations--do you? Btw I notice that the pickle module represents long ints as decimal strings even in "binary" mode, but I'll resist opening another bug for that, for now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-12 21:41 Message: Logged In: YES user_id=44345 If you head in the direction of documenting marshal with the aim of potentially interoperating with other languages, I think it would be a good idea to create a Python-independent marshal library. This would facilitate incorporation into other languages. Such a library probably wouldn't be able to do everything marshal can (there isn't an obvious C equivalent of Python's dictionary object, for example), but would still help nail down compatibility issues for the basic scalar types. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-12 21:09 Message: Logged In: YES user_id=31435 I'm not sure this is making progress. Paul, if you want to use marshal, you already can: the pack and unpack routines are exposed in Python via the marshal module. Freezing the representation isn't a particularly appealing idea; e.g., if anyone is likely to complain about the speed of Python's longs, it's you , and the current marshal format for longs is just a raw dump of Python's internal long representation -- but the most obvious everything-benefits way to speed Python longs is to increase the size of the "digits" used in its internal representation. If that's ever done, the marshal format would want to change too. It's easy enough to code your own storage format for longs, e.g. >>> def tobin(i): ... import binascii ... ashex = hex(long(i))[2:-1] # chop '0x' and trailing 'L' ... if len(ashex) & 1: ... ashex = '0' + ashex ... return binascii.unhexlify(ashex) implements "base 256" for unsigned longs, and the runtime cannot be improved by rewriting in C except by a constant factor (the Python spelling has the right O() behavior). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 20:24 Message: Logged In: YES user_id=6380 This helps tremendously. I think that marshal is probably overkill. Rather, you need helper routines to convert longs to and from binary. You can do everything else using the struct module, and it's probably easier to write your own protocol using that and these helpers. I suggest that the best place to add these helpers is the binascii module, which already has a bunch of similar things (e.g. hexlify and crc32). Note the xmlrpc is bundled with Python 2.2. Looking forward to your patch (much simpler to get accepted than a PEP :-). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 20:16 Message: Logged In: YES user_id=72053 Decimal is bad not just because of the data expansion but because the arithmetic to convert a decimal string to binary can be expensive (all that multiplication). I'd rather use hex than decimal for that reason. One envisioned application is communicating a cryptography coprocessor: an 8-bit microcontroller (with a public key accelerator) connected to the host computer through a slow serial port. Most of the ints involved would be around 300 decimal digits. A simple binary format is a lot easier to deal with in that environment than something like xmlrpc. Also, the format would be used for data persistence, so again, unnecessary data expansion isn't desirable. I looked at XMLRPC and it's not designed for this purpose. It's intended as an RPC protocol over HTTP and isn't well suited for object persistence. Also, it doesn't support integers over 32 bits, and binary strings must be base64 encoded (more bloat). Finally, it's not included with Python, so I'd have to bundle an implementation written in Python (i.e. slow) with my application (I don't know whether Fred's implementation is Python or C). I think the marshal format hasn't changed since before Python 1.5, so basing serialization on marshal would mean applications could interoperate with older versions of Python as well as newer ones, which helps Python's maturity. (Maturity of a program means, among other things, that users rarely need to be told they need the latest version in order to use some feature). Really, the marshal functions are written the way they're written because that's the simplest and most natural way of doing this kind of thing. So the proposal is mainly to make them available for user applications, rather than only for system internals. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 19:37 Message: Logged In: YES user_id=6380 If the PEP makes a reasonable case for freezing the spec, yes. I wonder why you can't use decimal? Are you talking really large volumes? The PEP needs to motivate this with an example, preferably plucked from real life! ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 19:29 Message: Logged In: YES user_id=72053 I just want to be able to do convenient transfers of python data to other programs including over the network. XMLRPC is excessive bloat in my opinion. Sending a number like 12345678 should take at most 5 bytes (a type byte and a 4-byte int) instead of 12345678. For long ints (300 digits) it's even worse. The marshal format is fine, and writing a PEP would solve the doc problem, but the current marshal doc says the non-specification is intentional. Writing it in a PEP means not just documenting--it means asking the language maintainers to freeze the marshal format of certain types, instead of reserving the right to change the format in future versions. Writing the PEP only makes sense if you're willing to freeze the format for those types (the other types can stay undocumented). Is that ok with you? Thanks Paul ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 14:33 Message: Logged In: YES user_id=6380 Paul, I don't understand the application that you are envisioning. If you think that the marshal format is what you want, why don't you write a PEP that specifies the format? That would solve the documentation problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-12 09:39 Message: Logged In: YES user_id=21627 Well, then I guess you need to specify your requirements more clearly. XML-RPC was precisely developed to be something simple for primitive types and structures that is sufficiently well-specified to allow interoperation between various languages. I don't see why extending the data 'by an order of magnitude' would be a problem per se, nor do I see why 'requiring a complicated parser' is a problem if the implementation already does all the unpacking for you under the hoods. Furthermore, I believe it is simply not true that XML-RPC expands the representation by an order of magnitude. For example, the Python Integer object 1 takes 12 bytes in its internal representation (plus the overhead that malloc requires); the XML-RPC representation '1' also uses 12 bytes. In short, you need to say as precise as possible what it is that you want, or you won't get it. Also, it may be that you have conflicting requirements (e.g. 'compact, binary', and 'simple, easily processible in different languages'); then you won't get it either. For a marshalling format that is accessible from different languages, you better specify it first, and implement it then. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 05:12 Message: Logged In: YES user_id=72053 I haven't looked at xmlrpclib, but I'm looking for a simple, compact, binary representation, not something that needs a complicated parser and expands the data by an order of magnitude. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-06 00:10 Message: Logged In: YES user_id=21627 So what's wrong with xmlrpclib? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467384&group_id=5470 From noreply@sourceforge.net Sat May 17 02:28:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:28:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-523425 ] shelve update fails on "large" entry Message-ID: Bugs item #523425, was opened at 2002-02-27 07:03 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523425&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: shelve update fails on "large" entry Initial Comment: Below is a Python script that demonstrates a possible bug when using the shelve module for: Python 2.2 MS Windows 2000 and 98 For 10k, shelve entries, the script works as expected, but for 15k entries, an exception is raised after "some" number of updates. I first tried to attach the script but received an error. # begin script """ Demonstration of possible update bug using shelve module for: Python 2.2 MS Windows 2000 and 98 """ __author__ = 'jim.vickroy@noaa.gov' import shelve def keys(): return [str(i) for i in range(100)] def archive(): return shelve.open('d:/logs/test') ##note = 'x'*10000 # this works note = 'x'*15000 # this fails with the following exception """ Traceback (most recent call last): File "C:\PYTHON22\lib\site- packages\Pythonwin\pywin\framework\scriptutils.py", line 301, in RunScript exec codeObject in __main__.__dict__ File "D:\py_trials\shelve_test.py", line 42, in ? File "D:\py_trials\shelve_test.py", line 23, in update db.close() File "C:\PYTHON22\lib\shelve.py", line 77, in __setitem__ self.dict[key] = f.getvalue() error: (0, 'Error') """ def update(): db = archive() for this in keys(): if db.has_key(this): entry = db[this] entry.append(note) else: entry = [note] db[this] = entry db.close() def validate(): db = archive() actual_keys = db.keys() expected_keys = keys() assert len(actual_keys) == len(expected_keys), \ 'expected %s -- got %s' % (len(expected_keys), len(actual_keys)) for this in keys(): entry = db[this] assert len(entry) == nbr_of_updates, \ 'expected %s -- got %s' % (nbr_of_updates, len(entry)) db.close() nbr_of_updates = 10 for i in range(nbr_of_updates): update() validate() # end script ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:28 Message: Logged In: YES user_id=357491 I actually get a failure with 2.3b1 under OS X at the first assert: Traceback (most recent call last): File "shelve_test.py", line 42, in ? validate() File "shelve_test.py", line 30, in validate assert len(actual_keys) == len(expected_keys), 'expected %s -- got %s' % (len(expected_keys), AssertionError: expected 100 -- got 0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523425&group_id=5470 From noreply@sourceforge.net Sat May 17 02:30:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:30:21 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-467384 ] provide a documented serialization func Message-ID: Feature Requests item #467384, was opened at 2001-10-02 19:25 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467384&group_id=5470 Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: provide a documented serialization func Initial Comment: It would be nice if there was a documented library function for serializing Python basic objects (numbers, strings, dictionaries, and lists). By documented I mean the protocol is specified in the documentation, precisely enough to write interoperating implementations in other languages. Code-wise, the marshal.dumps and loads functions do what I want, but their data format is (according to the documentation) intentionally not specified, because the format might change in future Python versions. Maybe that doc was written long enough ago that it's ok to freeze the marshal format now, and document it? I just mean for the basic types listed above. Stuff like code objects don't have to be specified. In fact it would be nice if there was a flag to the loads and dumps functions to refuse to marshal/ unmarshal those objects. Pickle/cpickle aren't really appropriate for what I'm asking, since they're complicated (they try to handle class instances, circular structure, etc.) and anyway they're not documented either. The XDR library is sort of ok, but it's written in Python (i.e. slow) and it doesn't automatically handle compound objects. Thanks ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:30 Message: Logged In: YES user_id=357491 RFE is specifically a feature request. I have gone ahead and reclassified this as such. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2003-05-16 18:17 Message: Logged In: YES user_id=72053 Yes, it's still an issue, even more than before since pickle is now explicitly documented to NOT be ok to use with untrusted data. This is already classified as a feature request. I don't know if an RFE is something different than that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 17:25 Message: Logged In: YES user_id=357491 Is this still an issue? If so, shouldn't this be made an RFE? ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-16 16:28 Message: Logged In: YES user_id=72053 Tim has opened a doc bug for pickle/marshal security issues as #471893. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-14 15:27 Message: Logged In: YES user_id=72053 My understanding of marshal (I better check it, but I did mention the issue in the original request) is that it can create code objects but it doesn't actually execute the code in them. My implementation currently uses marshal but checks that the stuff marshal returns doesn't contain anything unexpected. Unpickle is different--it looks like it can execute hostile code before the loads call ever returns. By the time you have a chance to check the result, it's too late. cPickle.c appears to work exactly the same way (using eval and creating arbitrary instances, but maybe not calling marshal) as pickle.py. It never would have occured to me that the unpickler would work that way (and I'm still not convinced I understand it--I better try putting together a test to see if it's really like that). That's why I didn't notice the security issue til we started discussing pickle and I actually looked at the code. I'm sorry if that sounds like I'm adding requirements. I'd have thought it would go without saying that an important utility shouldn't have security holes. I'm ok with using pickle if the doc and security concerns are taken care of. More efficient longs would be helpful but they would break interoperability with old versions and I can probably live without them. It's really sad that longs were shrugged off when the pickle binary format was designed. Now in order to have efficient longs, yet another flag will have to be added to the constructor. Btw, if the unpickle security issue is real (I'm still not convinced!), I feel it should be treated as a major bug and that an announcement should be sent out. Unpickle already anticipates hostile pickled strings in the non-binary format and checks for them (see _is_secure_string) though I'd want want to spend an hour or two checking both the `...` code and the evaluator before believing that _is_secure_string is really safe-- and even if it is, it's brittle. But it looks like object creation security is an area they didn't think about. Basically I have nothing against pickle in principle, but it has these (fixable) problems, and while marshal is straightforwardly written, both pickle implementations are excessively clever and make me queasy. Anyway, I can go along with the idea that the right solution is to fix pickle--but at present, pickle looks like it's in worse shape than marshal. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-14 13:36 Message: Logged In: YES user_id=31435 Ack -- Paul, you add a new hitherto secret requirement with each reply. marshal isn't secure at all: because its *purpose* is to load .pyc files, marshal creates Python code objects out of any bytes you happen to feed it following a "code object" tag. That's a hole big enough to swallow the solar system. In 2.2, marshal refuses to unpack code objects in restricted execution mode, but not before 2.2, and it never refuses in unrestricted mode. In contrast, pickle doesn't know anything about code objects, so doesn't have this hole. The pickle docs are clear about this, too, spelling out that marshal's code- object abilities create "the possibility of smuggling Trojan horses into a program". When wondering about security, you should be looking at (and using) cPickle.c instead of pickle.py; cPickle doesn't use marshal at all, nor does it do eval()s etc. Yes, it can reconstruct pickled instances of classes that already exist, but it cannot create new classes. I haven't heard that characterized as an insecurity before, but to each his own level of discomfort. I want to go back to the start: if the question is whether Python is interested in documenting another data transmission format, my answer is no. There are many already (don't forget the ones from the CORBA and ILU worlds either) available from Python, and there's no reason to believe encoders/decoders for a Python-specific format would get implemented in any other language. pickle is Python's generic answer to the Python-specific serialization question. I'd be happy to see patches to improve it (whether for efficient longs, or some stricter notion of security, or even just docs). But I expect any additional Python-specific serialization scheme has an audience of one (if you disagree, fine, write a PEP and get some community consensus). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 17:49 Message: Logged In: YES user_id=72053 I agree with Tim that the internal implementation of long arithmetic isn't relevant to this--it was just surprising, and means the current marshal format isn't all that natural for external use. I don't have a particular agenda to get marshal documented, beyond that it would happen to solve my immediate problem. Alternatives are fine too. The ones suggested so far just don't seem to do the job, viz.: xmlrpc does NOT serialize basic Python objects--in particular it doesn't serialize integers longer than 32 bits. I can't consider using pickle until I've convinced myself that it doesn't make security holes, and so far it looks like the opposite. (Can someone tell me I'm not reading it right?). Yes, of course, it's not that difficult to write Python code to do everything I want. It's just surprising that I should need to do that. I mean, imagine if there was no integer addition function (no "+" operator) and the maintainers said "that's ok, to add a and b, just use 'a - (-b)'". It's not a showstopping obstacle, but I'm surprised to get so much grief for suggesting making the operation more convenient, since it's an obvious thing to want to do (as evidenced by there already being so many overlapping serialization functions: marshal, pickle, rpclib, the Serialization class from Vaults of Parnassus, three different ASN1 implementations you mentioned, etc). I can't see anywhere where I've requested a "special gimmick". Yes, an efficient bigint representation in pickle is nice and ought to be added, but I can live without it. I can NOT live with security holes, but wanting security shouldn't be considered a special gimmick! With binary bigints, a documented format, and a way to 100% stop the unpickler from ever calling eval or apply on untrusted data, I wouldn't mind using pickle despite its additional complexity compared to marshal. I don't want to depend on third party modules unless I bundle them with my application (again not a showstopper, but it's not in Python's "batteries included" spirit to need them at all). Telling a user "to run this app, first download modules vreeble from and frob from " where url1 and url2 usually turn out to be broken links by the time the user sees them is not the right way to distribute an app. (It happens I'm going to sometimes tell the user "to run this app, first destroy your handheld computer's OS by reflashing the firmware..." but it's the principle of the thing, you know). Anyway, the 15 bit bigint representation is reason enough to not want to freeze the current marshal format. Maybe a future marshaller can use a cleaner bigint format and at that point perhaps the issue can be revisited. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 16:29 Message: Logged In: YES user_id=72053 A pickle subset ("gherkin"?) could possibly also fill this need, if it was documented, even though pickle format is considerably more complicated than marshal format (it uses marshal.dumps for binary output, actually taking apart the marshalled strings). It was obvious in seconds how marshal.c works but after 30 minutes of looking at pickle.py I'm still not sure I understand it. It looks like the unpickler can construct arbitrary class instances and import arbitrary modules, which makes a security hole if the pickled strings are potentially hostile, but I might not be reading it right. Also, the unpickler must implement constant folding (the memo scheme), which complicates it somewhat, though it's not that bad. The idea of leaving the marshal formats of some Python- specific objects undocumented isn't to get out of documenting stuff, but to leave those formats open to later change. Re BER/DER, Burt Kaliski's "Layman's Guide" is pretty readable (http://borg.isc.ucsb.edu/aka/Auth/ASN1layman.htm). You're right about using all 8 bits in BER integers--it looks like the 7 bit representation is only used for OID components (I didn't realize that til checking on it just now). BER might be ok for what I'm doing--I'm not sure right now since I don't understand ASN1 that well. It looks not in the spirit of marshal/pickle though: to encode a compound object it looks like you need an ASN1 spec of EXACTLY what you expect to find in the object. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 15:25 Message: Logged In: YES user_id=31435 Martin, you're right about add and sub, but it's a shallow assumption easy to relax (basically just declare carry/borrow as twodigits instead of digit). I'd be more worried about the stwodigits type, but since nothing is actually broken here I'm not keen to fritter away time proving bounds on the temps in bigint division. How we implement bigints internally is off topic anyway (provided we're not trying to hijack internal implementation formats for unintended purposes). About BER, yes, and the URL I included is to a freely downloadable copy of the X.690 std; section 8.3 spells out the INTEGER rules. They aren't at all the rules Paul sketched, hence "I don't really know what you [Paul] mean by 'BER'". For the rest, while xmlrcplib may meet the letter of what Paul asked for at first, it's clear to me that it doesn't meet what he really wants. My suggestion remains to add a new, efficient bigint format to pickle, which would meet everything except Paul's desire to have a special gimmick limited to his specific application and without having to write one himself. The internal API functions _PyLong_AsByteArray and _PyLong_FromByteArray already do the heavy lifting in both directions (to or from base 256, unsigned or complemented, big- or little-endian). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-13 14:04 Message: Logged In: YES user_id=21627 7-bit vs. 8-bit: You were confusing tag encoding and INTEGER value encoding. no way to encode a string with a length: suppose you want a 32 bit length, what's wrong with struct.pack("l",len(s))+s 15-bit representation: I believe the add and sub implementations make use of the guarantee that a short won't overflow if the input fits into 15 bits. Tim: BER = Basic Encoding Rules (as in the subtitle of X.690) Even after all this discussion, I still cannot see why the existing libraries (including those offered for free by third parties) are not sufficient. It appears that Paul wants, among other things, that marshal becomes documented; it also appears that this won't hapen. What the other things are that Paul wants, I cannot tell, so I recommend to close this report with "won't fix". Paul, if you have a specific change that you want to be made, or a specific problem that you want to point out, please submit a new report. This issue "provide a documented serialization func" really ought to be closed as "Fixed"; xmlrpclib is already part of standard library and fits the original problem description: - it is a library for serializing Python basic objects - it is documented in the sense that the protocol is specified precisely enough to write interoperating implementations in other languages. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 12:07 Message: Logged In: YES user_id=31435 I don't buy the argument that pickle is "complicated", as you weren't going to document the parts of the marshal format you didn't care about either. A subset of pickle is just as easy to document and implement across languages as a subset of marshal, but with the key benefit that the pickle format is stable across releases. So if you want a structure packer, pickle is the obvious choice; it just lacks an efficient (in time and space) scheme for storing longs now. And unlike marshal, it isn't a dead end when you decide your app needs something fancier -- pickle already handles just about everything that *can* be pickled, and is designed to be extensible to user-defined types too, so you can painlessly expand your view of what the "interesting" subset is as your ambitions grow. I don't really know what you mean by "BER". The ANS.1 std section 8.3 is quite clear that all 8 bits are used in each byte for integer representations -- it's a giant 2's-comp integer, with a variable-length length prefix, redundant sign bytes are forbidden, and there's nothing special about the last byte. I agree with Martin that ANS.1 BER is as compact a standardized bigint representation as there is. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-13 03:24 Message: Logged In: YES user_id=72053 1) if Python longs are currently implemented as vectors of 15-bit digits (yikes--why on earth would anyone do that) and marshalled like that, then I agree that THAT much weirdness doesn't need to be propagated to future versions. Wow! I never looked at the long int code closely, but the marshal code certainly didn't reflect that. It's still possible to freeze the current marshal format and let future versions define a new mechanism for loading .pyc's. >From my own self-interest (of wanting to distribute apps that work across versions) that idea attracts me, but it's probably not the right thing in the long run. Better may be to fix the long int format right away and THEN document/ freeze it. (Use a new format byte so the 2.2 demarshaller can still read 2.1 .pyc files). By "fix" I mean use a simple packed binary format, no 15 bit digits, no BER, and the length prefix should be a byte or bit count, not multibyte "digits". 2) Unfortunately it's not easy in portable C with 32 bit longs to use digits wider than 16 bits--multiplication becomes too complicated. If the compiler supports wide ints (long long int) then conditionalized code to use them might or might not be deemed worthwhile. Python's long int arithmetic (unlike Perl's Math::BigInt class) is fast enough to be useable for real applications and I don't expect it to go to the extremes that gmpy does (highly tuned algorithms for everything, asm code for many cpu's, etc). So currently I use gmpy when it's available and fall back on longs if gmpy won't import--this works pretty well so far. 3) I like the idea of a BER/DER library for Python but I don't feel like being the guy who writes it. I'd probably use it if it was available, though maybe not for this purpose. (I'd like to handle X509 certificates in Python). BER really isn't the most efficient way to store long ints, by the way, since it puts just 7 useful bits in a byte. 4) My suggestion of BER in 465045 was motivated slightly differently, which was to add a feature from Perl's pack/ unpack function that's missing from Python's struct.pack/ unpack. I understand a little better now what the struct module is for, so binascii may be a better place for such a thing. However, I believe Python really needs a pack/unpack module that does all the stuff that Perl's does. Data conversion like that is an area where Perl is still beating Python pretty badly. (Again, I don't feel like being the one who writes the module). 5) Sorry I didn't notice Guido's post of 20:24 earlier (several arrived at once). I guess I'm willing to submit a patch for binascii to read and write longs in binary. It's slightly humorous to put it in binascii since it's a binary-binary conversion with no ascii involved, but the function fits well there in any case. I'd still rather use marshal, since I want to write out more kinds of data than longs, and with a long->binary conversion function I'd still need to supply Python code to traverse dictionaries and lists, and encode strings. Btw, the struct module doesn't have any way to encode strings with a length, except the Pascal format which is limited to 256 bytes and is therefore useless for many things. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-13 01:39 Message: Logged In: YES user_id=31435 Martin, Paul suggested BER previously in 465045. I suspect he's going to suggest this for every module one by one, until somebody bites . I doubt he wants genuine ASN.1 BER, though, as that's a complicated beast, and he only cares about ints with a measly few hundred bits; regardless, a Python long can't have more digits than can be counted in a C int. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-13 01:14 Message: Logged In: YES user_id=21627 I would have never guessed that arbitrarily long ints are a requirement in your application... For that application, I'd recommend to use ASN.1 BER as a well-document, efficient, binary marshalling format. I don't think any other format marshals arbitrary large integers in a more compact form. You can find an implementation of that in http://www.cnri.reston.va.us/software/pisces/ or http://www.enteract.com/~asl2/software/PyZ3950/asn1.py or http://sourceforge.net/projects/pysnmp (ber.py) I'd be in favour of having a BER support library in the Python core, but somebody would have to contribute such a thing, of course. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-12 20:43 Message: Logged In: YES user_id=31435 The marshal long format actually uses 15-bit digits, each *stored* in 16 bits (the high bit of the high byte of which is always 0). That would be a PITA to preserve even if Python just moved to 16-bit digits. marshal's purpose is for efficient loading of .pyc files, where that odd format makes good sense; since it wasn't designed to be a general- purpose data transmission format (and has many shortcomings for such use), I don't want to see a tail wagging the dog here. Cross-release compatibility is taken seriously in pickle, and pickle handles many more cases than marshal, although pickle's author (as you've discovered) didn't give a hoot about efficient storage of longs. I'd rather add an efficient long format to pickle than hobble marshal (although because pickle does take x-release compatibility seriously, it has to continue accepting the "longs as decimal strings" format forever). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 20:08 Message: Logged In: YES user_id=72053 Skip - C has struct objects which are sort of like Python dictionaries. XMLRPC represents structs as name-value pairs, for example. And "other languages" doesn't necessarily mean C. The marshaller should be able to represent the non-Python-specific serializable objects, not just scalars. Basically this means strings, integers (of any length), dictionaries, lists, and floats (hmm--unicode?), but not necessarily stuff like code objects. Having an independent marshal library is ok, I guess, though I don't feel it's necessary to create more implementation work. And one the benefit of using the existing marshaller is that it's already available in most versions of Python that people are running (Red Hat 7.1 still comes with Python 1.5 for example). Tim - yes, I'm originally used a binascii.hexlify hack similar to yours and it worked ok, but it was ugly. I also had to handle strings (generate a length count followed by the contents) and then dictionaries (name-value pairs) and finally felt I shouldn't need to rewrite the marshaller like that. There's already a built-in library function that does everything I need, very efficiently in native code, in one call, and being able to use it is in the "batteries included" spirit. Also, the current long int marshalling format is just a digit count (16-bit digits) followed by the digits in binary. If the digit width changes, the marshalling format doesn't have to change--the marshalling code should still be able to use the same external representation without excessive contortions and without slowing down. (You'll see that it's already not a simple memory dump, but a structure read and written one byte at a time through layers of subroutines). Changing widths while keeping the old format means putting a minor kludge in the marshalling code, but no user will ever notice it. As for the speed of Python longs, my stuff's runtime is dominated by modular exponentiations and I'm already using gmpy for those when it's available (but I don't depend on it). The speedup with gmpy is substantial, but the speed with ordinary Python longs is quite acceptable on my PIII (the StrongARM is another story--probably the C compiler's fault). Examining Python/marshal.c, I don't see any objects of the types I've mentioned that are likely to need to change representations--do you? Btw I notice that the pickle module represents long ints as decimal strings even in "binary" mode, but I'll resist opening another bug for that, for now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-12 14:41 Message: Logged In: YES user_id=44345 If you head in the direction of documenting marshal with the aim of potentially interoperating with other languages, I think it would be a good idea to create a Python-independent marshal library. This would facilitate incorporation into other languages. Such a library probably wouldn't be able to do everything marshal can (there isn't an obvious C equivalent of Python's dictionary object, for example), but would still help nail down compatibility issues for the basic scalar types. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-12 14:09 Message: Logged In: YES user_id=31435 I'm not sure this is making progress. Paul, if you want to use marshal, you already can: the pack and unpack routines are exposed in Python via the marshal module. Freezing the representation isn't a particularly appealing idea; e.g., if anyone is likely to complain about the speed of Python's longs, it's you , and the current marshal format for longs is just a raw dump of Python's internal long representation -- but the most obvious everything-benefits way to speed Python longs is to increase the size of the "digits" used in its internal representation. If that's ever done, the marshal format would want to change too. It's easy enough to code your own storage format for longs, e.g. >>> def tobin(i): ... import binascii ... ashex = hex(long(i))[2:-1] # chop '0x' and trailing 'L' ... if len(ashex) & 1: ... ashex = '0' + ashex ... return binascii.unhexlify(ashex) implements "base 256" for unsigned longs, and the runtime cannot be improved by rewriting in C except by a constant factor (the Python spelling has the right O() behavior). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 13:24 Message: Logged In: YES user_id=6380 This helps tremendously. I think that marshal is probably overkill. Rather, you need helper routines to convert longs to and from binary. You can do everything else using the struct module, and it's probably easier to write your own protocol using that and these helpers. I suggest that the best place to add these helpers is the binascii module, which already has a bunch of similar things (e.g. hexlify and crc32). Note the xmlrpc is bundled with Python 2.2. Looking forward to your patch (much simpler to get accepted than a PEP :-). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 13:16 Message: Logged In: YES user_id=72053 Decimal is bad not just because of the data expansion but because the arithmetic to convert a decimal string to binary can be expensive (all that multiplication). I'd rather use hex than decimal for that reason. One envisioned application is communicating a cryptography coprocessor: an 8-bit microcontroller (with a public key accelerator) connected to the host computer through a slow serial port. Most of the ints involved would be around 300 decimal digits. A simple binary format is a lot easier to deal with in that environment than something like xmlrpc. Also, the format would be used for data persistence, so again, unnecessary data expansion isn't desirable. I looked at XMLRPC and it's not designed for this purpose. It's intended as an RPC protocol over HTTP and isn't well suited for object persistence. Also, it doesn't support integers over 32 bits, and binary strings must be base64 encoded (more bloat). Finally, it's not included with Python, so I'd have to bundle an implementation written in Python (i.e. slow) with my application (I don't know whether Fred's implementation is Python or C). I think the marshal format hasn't changed since before Python 1.5, so basing serialization on marshal would mean applications could interoperate with older versions of Python as well as newer ones, which helps Python's maturity. (Maturity of a program means, among other things, that users rarely need to be told they need the latest version in order to use some feature). Really, the marshal functions are written the way they're written because that's the simplest and most natural way of doing this kind of thing. So the proposal is mainly to make them available for user applications, rather than only for system internals. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 12:37 Message: Logged In: YES user_id=6380 If the PEP makes a reasonable case for freezing the spec, yes. I wonder why you can't use decimal? Are you talking really large volumes? The PEP needs to motivate this with an example, preferably plucked from real life! ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-12 12:29 Message: Logged In: YES user_id=72053 I just want to be able to do convenient transfers of python data to other programs including over the network. XMLRPC is excessive bloat in my opinion. Sending a number like 12345678 should take at most 5 bytes (a type byte and a 4-byte int) instead of 12345678. For long ints (300 digits) it's even worse. The marshal format is fine, and writing a PEP would solve the doc problem, but the current marshal doc says the non-specification is intentional. Writing it in a PEP means not just documenting--it means asking the language maintainers to freeze the marshal format of certain types, instead of reserving the right to change the format in future versions. Writing the PEP only makes sense if you're willing to freeze the format for those types (the other types can stay undocumented). Is that ok with you? Thanks Paul ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 07:33 Message: Logged In: YES user_id=6380 Paul, I don't understand the application that you are envisioning. If you think that the marshal format is what you want, why don't you write a PEP that specifies the format? That would solve the documentation problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-12 02:39 Message: Logged In: YES user_id=21627 Well, then I guess you need to specify your requirements more clearly. XML-RPC was precisely developed to be something simple for primitive types and structures that is sufficiently well-specified to allow interoperation between various languages. I don't see why extending the data 'by an order of magnitude' would be a problem per se, nor do I see why 'requiring a complicated parser' is a problem if the implementation already does all the unpacking for you under the hoods. Furthermore, I believe it is simply not true that XML-RPC expands the representation by an order of magnitude. For example, the Python Integer object 1 takes 12 bytes in its internal representation (plus the overhead that malloc requires); the XML-RPC representation '1' also uses 12 bytes. In short, you need to say as precise as possible what it is that you want, or you won't get it. Also, it may be that you have conflicting requirements (e.g. 'compact, binary', and 'simple, easily processible in different languages'); then you won't get it either. For a marshalling format that is accessible from different languages, you better specify it first, and implement it then. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 22:12 Message: Logged In: YES user_id=72053 I haven't looked at xmlrpclib, but I'm looking for a simple, compact, binary representation, not something that needs a complicated parser and expands the data by an order of magnitude. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-05 17:10 Message: Logged In: YES user_id=21627 So what's wrong with xmlrpclib? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467384&group_id=5470 From noreply@sourceforge.net Sat May 17 02:34:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:34:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event Message-ID: Bugs item #528295, was opened at 2002-03-10 16:34 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Carl J. Nobile (cnobile) Assigned to: A.M. Kuchling (akuchling) Summary: asyncore unhandled write event Initial Comment: I'm getting an unhandled write event on a handle_accept callback in asyncore.dispatch. This worked fine in python-2.1.1, but now seems to be broken in python-2.2. This happens when I send a SIGHUP to reread my config file. The signal lets me break out of the asyncore.loop() to reread the configuration and restart the server. The self.accept() method returns a TypeNone instead of the expected tuple when it is called in handle_accept. I've written a database key server which is a fairly large package and is dependent on a few other packages, so sending the code would not be too easy. If I can duplicate the problem in a few lines of code I will send it along at a later date. Thanks for your attention. Carl ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:34 Message: Logged In: YES user_id=357491 Was this ever brought up or resolved on python-dev like Andrew planned? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-22 09:24 Message: Logged In: YES user_id=11375 Revision 1.25 of asyncore.py is responsible. It catches EINTR and silently swallows the error, so sending signals to the process now doesn't cause it to exit asyncore's loop() at all. I don't see any unhandled write event at all. I'm not sure what to do here, and will take it up on python-dev. ---------------------------------------------------------------------- Comment By: Carl J. Nobile (cnobile) Date: 2002-03-20 19:47 Message: Logged In: YES user_id=482117 Okay, The version of asyncore.py from 2.1.1 when put into the 2.2 release solves the problem, so the bug seems to be in asyncore.py. I have cobbled together a server that displays the same error and am including it here. When run in 2.1.1 it works fine, reloading the config (just a print) with a kill -1 pid and terminating with a kill pid. Carl ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-16 12:36 Message: Logged In: YES user_id=11375 The asyncore.py in 2.1.1 seems to be revision 1.10 of the file; it's rev. 1.28 in 2.2 and is now at 1.30, so there have been a number of changes to asyncore, though none seem relevant. Did you try your code on 2.2 with the 2.1.1 asyncore? That would let us figure out if it's due to a change in asyncore or the underlying socket or select module. (Actually, another thing to check is whether the select or the poll module is being used; maybe that changed for you between 2.1.1 and 2.2.) ---------------------------------------------------------------------- Comment By: Carl J. Nobile (cnobile) Date: 2002-03-14 18:52 Message: Logged In: YES user_id=482117 My question then is why didn't it do this when I ran my app with python 2.1.1. Something has changed in 2.2 and I don't think it was asyncore, I do know some work was done to the low level socket and select modules so they could handle IPV6. I understand why the None is being returned, but an accept shouldn't even be called on a write event coming from a select or poll. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-14 15:24 Message: Logged In: YES user_id=11375 Looking at the implementation of accept() in asyncore.py, it will return None when the socket is in non-blocking mode and the accept() would block. There's really nothing else accept() could return in this case, so you'll probably have to write your code to handle this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470 From noreply@sourceforge.net Sat May 17 02:36:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:36:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-529135 ] test_pyclbr: bad dependency for input Message-ID: Bugs item #529135, was opened at 2002-03-12 13:35 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529135&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: test_pyclbr: bad dependency for input Initial Comment: Lib/test/test_pyclbr.py depends on the implementation details of other module (httplib in particular) for test data; it should not depend on that. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:36 Message: Logged In: YES user_id=357491 Looks like this is no longer the case. Closing this as out of date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529135&group_id=5470 From noreply@sourceforge.net Sat May 17 02:42:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:42:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-531145 ] socket.sslerror is not a socket.error Message-ID: Bugs item #531145, was opened at 2002-03-17 15:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: socket.sslerror is not a socket.error Initial Comment: Python 2.1.2 (#1, Mar 16 2002, 00:56:55) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import socket >>> socket.sslerror >>> try: raise socket.sslerror ... except socket.error: pass ... Traceback (most recent call last): File "", line 1, in ? socket.sslerror >>> ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:42 Message: Logged In: YES user_id=357491 Well, I have no issue with wanting to make socket.sslerror a subclass of socket.error, but socket.sslerror is not even documented so I don't see this as an issue until socket.sslerror is documented. So this will need a doc patch on top of any patch to make the change to socket.sslerror. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-04 08:19 Message: Logged In: YES user_id=670441 If this behavior is desired, the patch below implements it. If it's not desired, this bug sould be closed. It isn't much work at all. test_socket and test_socket_ssl still pass fine. The following case will work after this patch, all other combinations will work as before: >>> try: raise socket.sslerror ... except socket.error: print 'caught' caught >>> patch (I cannot attach the file in sourceforge for some reason): Index: dist/src/Modules/socketmodule.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.h,v retrieving revision 1.8 diff -c -r1.8 socketmodule.h *** dist/src/Modules/socketmodule.h 13 Jun 2002 15:07:44 -0000 1.8 --- dist/src/Modules/socketmodule.h 4 Feb 2003 16:05:27 -0000 *************** *** 140,145 **** --- 140,146 ---- /* C API for usage by other Python modules */ typedef struct { PyTypeObject *Sock_Type; + PyObject *Sock_Error; } PySocketModule_APIObject; /* XXX The net effect of the following appears to be to define a function Index: dist/src/Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.251 diff -c -r1.251 socketmodule.c *** dist/src/Modules/socketmodule.c 6 Jan 2003 12:41:26 -0000 1.251 --- dist/src/Modules/socketmodule.c 4 Feb 2003 16:05:43 -0000 *************** *** 3117,3122 **** --- 3117,3123 ---- PySocketModule_APIObject PySocketModuleAPI = { &sock_type, + NULL, }; *************** *** 3178,3183 **** --- 3179,3185 ---- return; /* Export C API */ + PySocketModuleAPI.Sock_Error = socket_error; if (PyModule_AddObject(m, PySocket_CAPI_NAME, PyCObject_FromVoidPtr((void *)&PySocketModuleAPI, NULL) ) != 0) Index: dist/src/Modules/_ssl.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_ssl.c,v retrieving revision 1.9 diff -c -r1.9 _ssl.c *** dist/src/Modules/_ssl.c 27 Jan 2003 22:19:21 -0000 1.9 --- dist/src/Modules/_ssl.c 4 Feb 2003 16:05:45 -0000 *************** *** 543,549 **** SSLeay_add_ssl_algorithms(); /* Add symbols to module dict */ ! PySSLErrorObject = PyErr_NewException("socket.sslerror", NULL, NULL); if (PySSLErrorObject == NULL) return; PyDict_SetItemString(d, "sslerror", PySSLErrorObject); --- 543,549 ---- SSLeay_add_ssl_algorithms(); /* Add symbols to module dict */ ! PySSLErrorObject = PyErr_NewException("socket.sslerror", PySocketModule.Sock_Error, NULL); if (PySSLErrorObject == NULL) return; PyDict_SetItemString(d, "sslerror", PySSLErrorObject); ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-11-11 09:12 Message: Logged In: YES user_id=9205 Yes, I want socket.sslerror to be a subclass of socket.error. It simplifies code layout (see my previous answer) and it follows the documentation. And yes, its work, but only a little :) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-04 17:05 Message: Logged In: YES user_id=163326 So do you propose to make socket.sslerror a subclass of socket.error. Is this desirable? I'm not sure. Is it work? Yes. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-03-18 12:23 Message: Logged In: YES user_id=9205 The documentation says for socket.error: "This exception is raised for socket- or address-related errors." I think socket.sslerror is such an error, because then you can write try: sock.write("") # could be ssl-socket except socket.error: pass The other way would be _exceptions = [socket.error] if hasattr(socket, "sslerror"): _exceptions.append(socket.sslerror) try: sock.write("") except _exceptions: pass Anyway, I assume this is a minor "bug". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-18 02:44 Message: Logged In: YES user_id=21627 Why is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470 From noreply@sourceforge.net Sat May 17 02:46:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:46:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python Message-ID: Bugs item #542482, was opened at 2002-04-11 05:48 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470 Category: Build Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Nobody/Anonymous (nobody) Summary: Problem compiling Python Initial Comment: Hi, I try to compile Python-2.2.1 on my linux slackware 8 with gcc-3.0.4 there was no problem with the configure, but for the make i got this : # gmake gcc -c -DNDEBUG -g -O3 -march=i686 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Python/thread.o Python/thread.c In file included from Python/thread.c:109: Python/thread_pth.h: In function `PyThread_start_new_thread': Python/thread_pth.h:59: warning: return makes integer from pointer without a cast In file included from Python/thread.c:113: Python/thread_pthread.h:113:1: warning: "CHECK_STATUS" redefined Python/thread_pth.h:31:1: warning: this is the location of the previous definition In file included from Python/thread.c:113: Python/thread_pthread.h: At top level: Python/thread_pthread.h:139: redefinition of `PyThread__init_thread' Python/thread_pth.h:38: `PyThread__init_thread' previously defined here Python/thread_pthread.h:154: redefinition of `PyThread_start_new_thread' Python/thread_pth.h:48: `PyThread_start_new_thread' previously defined here Python/thread_pthread.h:235: redefinition of `PyThread_get_thread_ident' Python/thread_pth.h:63: `PyThread_get_thread_ident' previously defined here Python/thread_pthread.h:250: redefinition of `do_PyThread_exit_thread' Python/thread_pth.h:73: `do_PyThread_exit_thread' previously defined here Python/thread_pthread.h:262: redefinition of `PyThread_exit_thread' Python/thread_pth.h:84: `PyThread_exit_thread' previously defined here Python/thread_pthread.h:268: redefinition of `PyThread__exit_thread' Python/thread_pth.h:89: `PyThread__exit_thread' previously defined here Python/thread_pthread.h:302: redefinition of `PyThread_allocate_lock' Python/thread_pth.h:119: `PyThread_allocate_lock' previously defined here Python/thread_pthread.h:335: redefinition of `PyThread_free_lock' Python/thread_pth.h:145: `PyThread_free_lock' previously defined here Python/thread_pthread.h:352: redefinition of `PyThread_acquire_lock' Python/thread_pth.h:154: `PyThread_acquire_lock' previously defined here Python/thread_pthread.h:390: redefinition of `PyThread_release_lock' Python/thread_pth.h:191: `PyThread_release_lock' previously defined here Python/thread_pthread.h:413: redefinition of `struct semaphore' Python/thread_pthread.h:421: redefinition of `PyThread_allocate_sema' Python/thread_pth.h:221: `PyThread_allocate_sema' previously defined here Python/thread_pthread.h:449: redefinition of `PyThread_free_sema' Python/thread_pth.h:246: `PyThread_free_sema' previously defined here Python/thread_pthread.h:463: redefinition of `PyThread_down_sema' Python/thread_pth.h:254: `PyThread_down_sema' previously defined here Python/thread_pthread.h:493: redefinition of `PyThread_up_sema' Python/thread_pth.h:283: `PyThread_up_sema' previously defined here gmake: *** [Python/thread.o] Error 1 It would be great if you could help me with this ! Best regards, Pierre. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:46 Message: Logged In: YES user_id=357491 Anyone care to answer Neal's question? =) Might be nice to see if this can be solved before 2.2.3 goes out the door. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 18:45 Message: Logged In: YES user_id=33168 Is this still a problem w/2.2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-13 16:04 Message: Logged In: YES user_id=21627 You are right; this is the intention. It turns out that a configuration of an alternate thread library is not supported if pthreads are also available on the system. I'll try to come up with a work-around, but this is not high-priority, and may take a while. ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-13 06:18 Message: Logged In: YES user_id=512388 I did ./configure --with-threads --with-pth I thought it means "enable thread support, and for this use gnu pth". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-13 01:31 Message: Logged In: YES user_id=21627 I think I can see the problem now. For some reason, Python tries to use both GNU pth and pthreads for threading; this cannot work. How did you invoke configure? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-12 19:29 Message: Logged In: YES user_id=512388 In fact i can't attach the file thread.i, it is too big :( ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-12 19:26 Message: Logged In: YES user_id=512388 Ok i have done : root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3 -march=i686 -Wall -Wstrict-prototypes -dD --save-temps --trace-includes -I. -I./Include -DHAVE_CONFIG_H -o Python/thread.o Python/thread.c >& compile.log I attach you the file compile.log and the file thread.i ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-11 14:59 Message: Logged In: YES user_id=21627 Can you please add the options "-dD --save-temps --trace-includes" to the gcc invocation, and attach both the compiler (error) output and thread.i to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470 From noreply@sourceforge.net Sat May 17 02:48:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:48:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-542482 ] Can't compile when using alt. thread lib when pthread avail. Message-ID: Bugs item #542482, was opened at 2002-04-11 05:48 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470 Category: Build Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Nobody/Anonymous (nobody) >Summary: Can't compile when using alt. thread lib when pthread avail. Initial Comment: Hi, I try to compile Python-2.2.1 on my linux slackware 8 with gcc-3.0.4 there was no problem with the configure, but for the make i got this : # gmake gcc -c -DNDEBUG -g -O3 -march=i686 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Python/thread.o Python/thread.c In file included from Python/thread.c:109: Python/thread_pth.h: In function `PyThread_start_new_thread': Python/thread_pth.h:59: warning: return makes integer from pointer without a cast In file included from Python/thread.c:113: Python/thread_pthread.h:113:1: warning: "CHECK_STATUS" redefined Python/thread_pth.h:31:1: warning: this is the location of the previous definition In file included from Python/thread.c:113: Python/thread_pthread.h: At top level: Python/thread_pthread.h:139: redefinition of `PyThread__init_thread' Python/thread_pth.h:38: `PyThread__init_thread' previously defined here Python/thread_pthread.h:154: redefinition of `PyThread_start_new_thread' Python/thread_pth.h:48: `PyThread_start_new_thread' previously defined here Python/thread_pthread.h:235: redefinition of `PyThread_get_thread_ident' Python/thread_pth.h:63: `PyThread_get_thread_ident' previously defined here Python/thread_pthread.h:250: redefinition of `do_PyThread_exit_thread' Python/thread_pth.h:73: `do_PyThread_exit_thread' previously defined here Python/thread_pthread.h:262: redefinition of `PyThread_exit_thread' Python/thread_pth.h:84: `PyThread_exit_thread' previously defined here Python/thread_pthread.h:268: redefinition of `PyThread__exit_thread' Python/thread_pth.h:89: `PyThread__exit_thread' previously defined here Python/thread_pthread.h:302: redefinition of `PyThread_allocate_lock' Python/thread_pth.h:119: `PyThread_allocate_lock' previously defined here Python/thread_pthread.h:335: redefinition of `PyThread_free_lock' Python/thread_pth.h:145: `PyThread_free_lock' previously defined here Python/thread_pthread.h:352: redefinition of `PyThread_acquire_lock' Python/thread_pth.h:154: `PyThread_acquire_lock' previously defined here Python/thread_pthread.h:390: redefinition of `PyThread_release_lock' Python/thread_pth.h:191: `PyThread_release_lock' previously defined here Python/thread_pthread.h:413: redefinition of `struct semaphore' Python/thread_pthread.h:421: redefinition of `PyThread_allocate_sema' Python/thread_pth.h:221: `PyThread_allocate_sema' previously defined here Python/thread_pthread.h:449: redefinition of `PyThread_free_sema' Python/thread_pth.h:246: `PyThread_free_sema' previously defined here Python/thread_pthread.h:463: redefinition of `PyThread_down_sema' Python/thread_pth.h:254: `PyThread_down_sema' previously defined here Python/thread_pthread.h:493: redefinition of `PyThread_up_sema' Python/thread_pth.h:283: `PyThread_up_sema' previously defined here gmake: *** [Python/thread.o] Error 1 It would be great if you could help me with this ! Best regards, Pierre. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:46 Message: Logged In: YES user_id=357491 Anyone care to answer Neal's question? =) Might be nice to see if this can be solved before 2.2.3 goes out the door. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 18:45 Message: Logged In: YES user_id=33168 Is this still a problem w/2.2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-13 16:04 Message: Logged In: YES user_id=21627 You are right; this is the intention. It turns out that a configuration of an alternate thread library is not supported if pthreads are also available on the system. I'll try to come up with a work-around, but this is not high-priority, and may take a while. ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-13 06:18 Message: Logged In: YES user_id=512388 I did ./configure --with-threads --with-pth I thought it means "enable thread support, and for this use gnu pth". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-13 01:31 Message: Logged In: YES user_id=21627 I think I can see the problem now. For some reason, Python tries to use both GNU pth and pthreads for threading; this cannot work. How did you invoke configure? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-12 19:29 Message: Logged In: YES user_id=512388 In fact i can't attach the file thread.i, it is too big :( ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-12 19:26 Message: Logged In: YES user_id=512388 Ok i have done : root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3 -march=i686 -Wall -Wstrict-prototypes -dD --save-temps --trace-includes -I. -I./Include -DHAVE_CONFIG_H -o Python/thread.o Python/thread.c >& compile.log I attach you the file compile.log and the file thread.i ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-11 14:59 Message: Logged In: YES user_id=21627 Can you please add the options "-dD --save-temps --trace-includes" to the gcc invocation, and attach both the compiler (error) output and thread.i to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470 From noreply@sourceforge.net Sat May 17 02:53:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 18:53:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-545855 ] Wrong exception from re.compile() Message-ID: Bugs item #545855, was opened at 2002-04-18 15:22 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545855&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Wrong exception from re.compile() Initial Comment: re.compile('foo[a-') raises a TypeError exception instead of re.error. Python 2.2.1 (#1, Apr 4 2002, 17:22:15) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.compile('foo[a-') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/sre.py", line 178, in compile return _compile(pattern, flags) File "/usr/local/lib/python2.2/sre.py", line 226, in _compile p = sre_compile.compile(pattern, flags) File "/usr/local/lib/python2.2/sre_compile.py", line 430, in compile p = sre_parse.parse(p, flags) File "/usr/local/lib/python2.2/sre_parse.py", line 623, in parse p = _parse_sub(source, pattern, 0) File "/usr/local/lib/python2.2/sre_parse.py", line 318, in _parse_sub items.append(_parse(source, state)) File "/usr/local/lib/python2.2/sre_parse.py", line 424, in _parse if this[0] == "\": TypeError: unsubscriptable object ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:53 Message: Logged In: YES user_id=357491 This is fixed in 2.2.2 and 2.3b1. Closing as out of date. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-04 12:02 Message: Logged In: YES user_id=670441 Patch below fixes the problem. Didn't check for end of expression in one case. Index: dist/src/Lib/sre_parse.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/sre_parse.py,v retrieving revision 1.55 diff -c -r1.55 sre_parse.py *** dist/src/Lib/sre_parse.py 2 Jun 2002 00:40:05 -0000 1.55 --- dist/src/Lib/sre_parse.py 4 Feb 2003 19:53:14 -0000 *************** *** 420,429 **** set.append((LITERAL, ord("-"))) break else: ! if this[0] == "\": code2 = _class_escape(source, this) ! else: code2 = LITERAL, ord(this) if code1[0] != LITERAL or code2[0] != LITERAL: raise error, "bad character range" lo = code1[1] --- 420,431 ---- set.append((LITERAL, ord("-"))) break else: ! if this and this[0] == "\": code2 = _class_escape(source, this) ! elif this: code2 = LITERAL, ord(this) + else: + raise error, "unexpected end of regular expression" if code1[0] != LITERAL or code2[0] != LITERAL: raise error, "bad character range" lo = code1[1] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545855&group_id=5470 From noreply@sourceforge.net Sat May 17 03:00:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:00:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-546059 ] regex segfault on Mac OS X Message-ID: Bugs item #546059, was opened at 2002-04-19 03:51 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546059&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Fredrik Lundh (effbot) Summary: regex segfault on Mac OS X Initial Comment: I attach a Python script and a data file. Run it this way to reproduce the segfault: ./bug.py data.txt I can't reproduce the bug on Solaris or Linux, only Mac OS X. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:00 Message: Logged In: YES user_id=357491 Can't reproduce under 2.2.2 or 2.3b1 using OS X 10.2.6 . Closing as out of date. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-19 15:07 Message: Logged In: NO I also get a lot of segfaults in the re module on Mac OS X.1-2. Example: md% python Python 2.2 (#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ^D md% cat test.py import re, urllib rdf_re = re.compile(r'.*?)"\s+dc:title="(?P.*?)"\s+dc:identifier="(?P<identifier>.*?)".*?/>', re.DOTALL|re.IGNORECASE) x = urllib.urlopen('http://hit-or-miss.org/projects/trackback/').read() print re.findall(rdf_re, x) md% python test.py Segmentation fault md% gdb python GNU gdb 5.1-20020408 (Apple version gdb-228) (Sun Jul 14 10:07:24 GMT 2002) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-macos10". Reading symbols for shared libraries .... done (gdb) set args test.py (gdb) run Starting program: /usr/bin/python test.py [Switching to process 1113 thread 0xb03] Agent pid 439 Reading symbols for shared libraries ............. done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. 0x0007d8f8 in PyMember_SetOne () (gdb) (gdb) backtrace #0 0x0007d8f8 in PyMember_SetOne () #1 0x0007e124 in PyMember_SetOne () #2 0x0007e124 in PyMember_SetOne () #3 0x0007e124 in PyMember_SetOne () ... #4065 0x0007e3a8 in PyMember_SetOne () #4066 0x00080864 in PyMember_SetOne () #4067 0x00045930 in PyObject_Call () #4068 0x0005df64 in PyEval_GetFuncDesc () #4069 0x0005b1f8 in PyEval_EvalCode () #4070 0x0005c634 in PyEval_EvalCodeEx () #4071 0x0005db9c in PyEval_GetFuncDesc () #4072 0x0005b314 in PyEval_EvalCode () #4073 0x0005c634 in PyEval_EvalCodeEx () #4074 0x00058a80 in PyEval_EvalCode () #4075 0x00027e90 in PyRun_FileExFlags () #4076 0x00026ef4 in PyRun_SimpleFileExFlags () #4077 0x000069f0 in Py_Main () #4078 0x00002970 in start () #4079 0x000027f0 in start () (gdb) ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2002-04-19 05:43 Message: Logged In: YES user_id=52414 I've run the same program with MacPython instead of Python for Mac OS X from Fink and I now get a "maximum recursion limit exceeded" so this may be a duplicate of similar bug reports: 418626 437472 493252 except that I can reproduce this with Python 2.2. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2002-04-19 03:53 Message: Logged In: YES user_id=52414 This was reproduced using the Python 2.2 for Mac OS X from Fink, version (#1 Jan 9, 2002) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546059&group_id=5470 From noreply@sourceforge.net Sat May 17 03:19:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:19:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-560064 ] inconsistent behavior of __getslice__ Message-ID: <E19GrHw-0004Sk-00@sc8-sf-web3.sourceforge.net> Bugs item #560064, was opened at 2002-05-24 04:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cesar Douady (douady) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistent behavior of __getslice__ Initial Comment: The following trace shows what I mean: >>> help(str.__getslice__) Help on wrapper_descriptor: __getslice__(...) x.__getslice__(i, j) <==> x[i:j] >>> 'ab'[-1] 'b' >>> 'ab'.__getitem__(-1) 'b' >>> 'ab'[-2:-1] 'a' >>> 'ab'.__getslice__(-2,-1) '' that is, __getslice__ does not add the length of the sequence to its arguments when they are negative as indexing with [:] does. This contradicts the docstring which says __getslice__ is equivalent to indexing. The same behavior applies to lists. Note that __getitem__ does it right. This bug may be linked to bug 473985 ('str, __getitem__ and slices') but should be much easier to fix. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:19 Message: Logged In: YES user_id=357491 If the docstring fix is still the best way to fix this I am willing to make the change. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 12:23 Message: Logged In: YES user_id=6380 This should NOT be fixed this way, Raymond! The docs are (subtly) wrong. For historical reasons, __getslice__ expects the Python VM to do the adjustment of negative indices. If you did another adjustment inside getslice, certain indices would start behaving differently (e.g. s[:-5] where len(s)==3). Maybe the docstring should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 05:58 Message: Logged In: YES user_id=80475 Tim, I attached a tiny patch which fixes the behavior for strings. I've also tried out the same change in listobject.c and unicodeobject.c. Is this the right this to do or are there more subtleties to this than meet the eye? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470 From noreply@sourceforge.net Sat May 17 03:22:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:22:49 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-739029 ] Constructor for counting things Message-ID: <E19GrLV-0004MK-00@sc8-sf-web4.sourceforge.net> Feature Requests item #739029, was opened at 2003-05-17 02:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Constructor for counting things Initial Comment: Counting things is very common. May I suggest an alternate dictionary constructor that works like this: class BetterDictionary(dict): def bag(classobject, sequence): "Fast way to count things" b = classobject() for k in sequence: b[k] = b.get(k,0) + 1 return b bag = classmethod(bag) print BetterDictionary.bag("jack and jill went up a hill ...") A C implementation could do this very fast. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470 From noreply@sourceforge.net Sat May 17 03:28:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:28:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-554750 ] Circular reference in Index for frame Message-ID: <E19GrQk-0004TX-00@sc8-sf-web4.sourceforge.net> Bugs item #554750, was opened at 2002-05-10 20:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554750&group_id=5470 Category: Documentation Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Circular reference in Index for frame Initial Comment: I hope you don't mind all my anal retentive documentation bugs ;-) In the Python Library Index: http://www.python.org/dev/doc/devel/lib/genindex.html Go to 'F' and look up 'frame object'. http://www.python.org/dev/doc/devel/lib/module- signal.html#l2h-1870 It takes you to the signal documentation here: "The handler is called with two arguments: the signal number and the current stack frame (None or a frame object; see the reference manual for a description of frame objects)." Besides this circular reference, as far as I can tell the frame object and it's use in a signal handler is undocumented. Frame Objects are mentioned in the Python Reference Manual Index, but the named anchor is not correct. It does link to the correct page, but it brings you to the top of the page, whereas Frame Objects are not mentioned until much farther down the page. This is the link given in the Index: http://www.python.org/dev/doc/devel/ref/types.html#l2h- 59 The details of Frame Objects are still rather fuzzy. Yours, Noah ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:28 Message: Logged In: YES user_id=357491 The use of the frame object is up to you. Most people would use it to inspect the frame to see where they were when the signal was raised. Since the use is completely up to the user it is not specified. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554750&group_id=5470 From noreply@sourceforge.net Sat May 17 03:34:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:34:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: <E19GrX7-0004oQ-00@sc8-sf-web3.sourceforge.net> Bugs item #570300, was opened at 2002-06-17 18:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amit Aronovitch (amitar) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply@sourceforge.net Sat May 17 03:36:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:36:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-575770 ] os.spawnv() fails with underscores Message-ID: <E19GrYu-0005FB-00@sc8-sf-web2.sourceforge.net> Bugs item #575770, was opened at 2002-06-30 15:15 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Rodrigues (nokta_kanto) Assigned to: Nobody/Anonymous (nobody) Summary: os.spawnv() fails with underscores Initial Comment: I'm running Python 2.2 in Windows 98. When trying to os.spawnv() a program in a path that contains an underscore, the program does not run but no error message is printed. This error happens in the dos version of Python 2.2, but not in IDLE. I detected the error by creating a DOS program that returns the recognizable value 111. If I call that file "c:\ret111.exe" and run it with the following command: os.spawnv( os.P_WAIT, progname, [progname] ) where progname is the full path and name of the program, then the function returns the value 111. If I put that file in "c:\pulse_prog\ret111.exe", and run the same command with the new value of progname, then the return value is 111 in IDLE but 0 in dos-prompt python. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:36 Message: Logged In: YES user_id=357491 Can anyone with Win98 test this to see if this is still a bug? ---------------------------------------------------------------------- Comment By: Chris Rodrigues (nokta_kanto) Date: 2002-08-06 15:54 Message: Logged In: YES user_id=571002 I've attached the binary file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-30 07:27 Message: Logged In: YES user_id=21627 Can you please attach the binary to this report? ---------------------------------------------------------------------- Comment By: Chris Rodrigues (nokta_kanto) Date: 2002-07-19 14:22 Message: Logged In: YES user_id=571002 Here's a screen dump of the error in progress. I don't know if it makes a difference, but ret111.exe was compiled with djgpp. C:\pulse_prog>type ret111.c int main() {return 111;} C:\pulse_prog>python Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.spawnv( os.P_WAIT, r'c:\ret111.exe', [r'c:\ret111.exe']) 111 >>> os.spawnv( os.P_WAIT, r'c:\pulse_prog\ret111.exe', [r'c:\pulse_prog\ret111.exe']) 0 >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-05 09:46 Message: Logged In: YES user_id=31435 I can't reproduce this using 2.2.1 under Win98SE. Here's a screen dump showing exactly what I did. Please show us exactly what you did. C:\pulse_prog>type ret111.c int main() { return 111; } C:\pulse_prog>cd \python22 C:\Python22>python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> prog = r"c:\pulse_prog\ret111" >>> os.spawnv(os.P_WAIT, prog, [prog]) 111 >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-04 22:52 Message: Logged In: YES user_id=21627 Can you please attach the test program to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470 From noreply@sourceforge.net Sat May 17 03:39:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:39:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-576990 ] inheriting from property and docstrings Message-ID: <E19GrbR-0004tu-00@sc8-sf-web3.sourceforge.net> Bugs item #576990, was opened at 2002-07-03 07:42 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Guido van Rossum (gvanrossum) Summary: inheriting from property and docstrings Initial Comment: If I inherit from property, and try to initialize a derived property object, the doc string doesn't get set. This bug was introduced in 2.2.1, and is present in 2.3a0: Compare: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ hi and, Python 2.2.1 (#1, Jun 16 2002, 16:19:48) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ None There is no problem with the getter/setter functions passed to the constructor. i.e.: myprop(f,g,h,None) works identical in 2.2 and 2.2.1 Good luck, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:39 Message: Logged In: YES user_id=357491 I vaguely remember this coming on up on python-dev and it being said that this would not get fixed. Am I remembering correctly? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-24 10:01 Message: Logged In: YES user_id=6380 The problem is that class myprop has a __doc__ in its class __dict__ that is the docstring for myprop, or None if that class has no docstring. The march through the MRO looking for an instance attribute descriptor finds this before it would ever get to the property class, so effectively a __doc__ property is not inherited. The simplest workaround I found is this: class myprop(property): __doc__ = property.__dict__['__doc__'] (__doc__ = property.__doc__ does not do the right thing, it gets the property class's docstring rather than the descriptor.) This is a mess. I'll have to think about whether it's possible at all to fix it without breaking something else. I'll also have to think about whether it's worth it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-24 06:12 Message: Logged In: YES user_id=11105 Ups, forget my patch. Nothing works, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-24 06:06 Message: Logged In: YES user_id=11105 The attached simple fix (descrobj.diff) fixes the problem for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-24 05:43 Message: Logged In: YES user_id=6380 OK, I'll have a look. We've have numerous hacks upon hacks to get __doc__ to behave right. I don't know if it is within my powers to fix this without breaking other things. But if it is, I'll try to fix it in 2.2.1 as well as 2.3. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-09-09 03:49 Message: Logged In: YES user_id=302601 To give a usage example: (because rhettinger thought this was a very strange use of properties, and, for all I know, he may be right) >>> class typed_property(property): ... def __init__(self, tp, doc): ... def getter(inst): ... return inst.__dict__[self] ... def setter(inst, val): ... if not isinstance(val, tp): ... raise TypeError ... inst.__dict__[self] = val ... property.__init__(self, getter, setter, ... None, doc) ... >>> class A(object): ... a = typed_property(int, 'a prop') ... >>> inst = A() >>> inst.a = 1 >>> print inst.a 1 >>> inst.a = 'a' Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 7, in setter TypeError >>> A.a.__doc__ 'a prop' The last only works in 2.2, and then only if typed_property itself has no doc string ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 15:11 Message: Logged In: YES user_id=80475 Okay, now I see what you're trying to do. Still, it the strangest use of property that I've seen to-date. Re-opening the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 14:55 Message: Logged In: YES user_id=80475 I think this is based on a misunderstanding of how to use property. Instead of inheriting from it, you use it as a function call in a new-style class (derived from object): This works fine in versions from 2.2 upto 2.3a: >>> class Myprop(object): a = property(None,None,None,'a sample docstring') >>> Myprop.a.__doc__ 'a sample docstring' Marking as invalid and closing. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-09 04:52 Message: Logged In: YES user_id=302601 I think I found the problem, Compare: >>> property.__doc__ 'property(fget=None,.... # the doc string and >>> property.__dict__['__doc__'] <member '__doc__' of 'property' objects> Note that property.__doc__ and property.__dict__['__doc__'] are not the same. Python will go out of its way to prevent this weird situation in user derived classes., 1. type_new(name, bases, attrs) will copy attrs to new_tp.tp_dict, and will also copy attrs['__doc__'] to tp.tp_doc 2. PyType_Ready(tp) will copy tp.tp_doc to tp.tp_dict['__doc__'] if tp.tp_dict['__doc__'] is undefined This guarantees that tp.tp_dict['__doc__'] will exist, usually copying tp.tp_doc, and shadowing property.tp_dict['__doc__'] if tp is derived from property The solution seems to be: 1. In type_new(): if possible copy attr['__doc__'] to tp.tp_doc, and delete __doc__ from attr (to prevent ending up in tp_dict) 2. in PyType_Ready(): don't copy tp.tp_doc to tp_dict['__doc__'] These two steps make sure that, tp_dict['__doc__'] no longer shadows properties.tp_dict['__doc__']. Unfortunately, this means that tp.__doc__ doesn't generally return the docstrings for user-defined types. Therefore: 3. in type_get_doc(): return tp.tp_doc also for heap types. The result of this will be: 1. properties will be subclassable again. (good) 2. __doc__ string become read-only attributes (bad??) 3. test cases in test_descr that assume that instance.__dict__['__doc__'] exists, will fail 4. a weird test_failure in test_module.py Patches for this modification are attached, except for (test_module.py), which I don't understand. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-08 05:23 Message: Logged In: YES user_id=302601 Some more details: In fact 2.2.1 is consistently wrong, whereas 2.2 is inconsistently right ;), compare: Python 2.2.1 (#20, Jul 8 2002, 13:25:14) [GCC 3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ None >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string and Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ Hi there >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string So, in 2.2.1 myprop(...).__doc__ will allways return myprop.__doc__. In 2.2 myprop.__doc__ will return the instance's __doc__, iff myprop.__doc__ is None. For the record: I was expecting 'Hi there' (i.e. obj->prop_doc), as in: >>> property(None, None, None, 'Hi there').__doc__ 'Hi there' Hope this helps, Roeland ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 From noreply@sourceforge.net Sat May 17 03:40:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 19:40:13 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-577295 ] Print line number of string if at EOF Message-ID: <E19GrcL-0007E4-00@sc8-sf-web1.sourceforge.net> Feature Requests item #577295, was opened at 2002-07-04 00:31 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=577295&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: Print line number of string if at EOF Initial Comment: It would be good if the python parser would tell me where the string started if it reaches EOF (end of file) in the string. If you leave a '''-string open you just get SyntaxError at EOF. Printing the line number where the string started would be helpfull. thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=577295&group_id=5470 From noreply@sourceforge.net Sat May 17 04:10:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 20:10:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-575770 ] os.spawnv() fails with underscores Message-ID: <E19Gs5S-0005Yc-00@sc8-sf-web4.sourceforge.net> Bugs item #575770, was opened at 2002-06-30 18:15 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Rodrigues (nokta_kanto) >Assigned to: Martin v. Löwis (loewis) Summary: os.spawnv() fails with underscores Initial Comment: I'm running Python 2.2 in Windows 98. When trying to os.spawnv() a program in a path that contains an underscore, the program does not run but no error message is printed. This error happens in the dos version of Python 2.2, but not in IDLE. I detected the error by creating a DOS program that returns the recognizable value 111. If I call that file "c:\ret111.exe" and run it with the following command: os.spawnv( os.P_WAIT, progname, [progname] ) where progname is the full path and name of the program, then the function returns the value 111. If I put that file in "c:\pulse_prog\ret111.exe", and run the same command with the new value of progname, then the return value is 111 in IDLE but 0 in dos-prompt python. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-16 23:10 Message: Logged In: YES user_id=31435 Assigned to Martin since he asked for the binary, and I don't know what he wanted to do with it. I tried it (still on Win98SE), and I do get a return value of 0 from spawnv -- sometimes. It doesn't have anything to do with whether there's an underscore in the path name for me, it has solely to do with whether the directory name has more than 8 characters. So, using: c:\pulse_prog\ret111.exe -- returns 0 c:\pulseprog\ret111.exe -- returns 0 c:\pulsepro\ret111.exe -- returns 111 More, this doesn't appear to have anything to do with Python. I get the same results with this straight C program, compiled under MSVC 6: #include <stdio.h> #include <process.h> void main() { int rc; char *prog = "c:\pulseprog\ret111.exe"; char *whatever[] = {prog, 0}; rc = _spawnv(_P_WAIT, prog, whatever); printf("return code %d\n", rc); } I have to conclude this has something to do with the compiler Chris is using. It doesn't appear to be a Python bug in any case. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 22:36 Message: Logged In: YES user_id=357491 Can anyone with Win98 test this to see if this is still a bug? ---------------------------------------------------------------------- Comment By: Chris Rodrigues (nokta_kanto) Date: 2002-08-06 18:54 Message: Logged In: YES user_id=571002 I've attached the binary file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-30 10:27 Message: Logged In: YES user_id=21627 Can you please attach the binary to this report? ---------------------------------------------------------------------- Comment By: Chris Rodrigues (nokta_kanto) Date: 2002-07-19 17:22 Message: Logged In: YES user_id=571002 Here's a screen dump of the error in progress. I don't know if it makes a difference, but ret111.exe was compiled with djgpp. C:\pulse_prog>type ret111.c int main() {return 111;} C:\pulse_prog>python Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.spawnv( os.P_WAIT, r'c:\ret111.exe', [r'c:\ret111.exe']) 111 >>> os.spawnv( os.P_WAIT, r'c:\pulse_prog\ret111.exe', [r'c:\pulse_prog\ret111.exe']) 0 >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-05 12:46 Message: Logged In: YES user_id=31435 I can't reproduce this using 2.2.1 under Win98SE. Here's a screen dump showing exactly what I did. Please show us exactly what you did. C:\pulse_prog>type ret111.c int main() { return 111; } C:\pulse_prog>cd \python22 C:\Python22>python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> prog = r"c:\pulse_prog\ret111" >>> os.spawnv(os.P_WAIT, prog, [prog]) 111 >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-05 01:52 Message: Logged In: YES user_id=21627 Can you please attach the test program to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470 From noreply@sourceforge.net Sat May 17 09:15:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 01:15:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-575770 ] os.spawnv() fails with underscores Message-ID: <E19GwqL-00071B-00@sc8-sf-web1.sourceforge.net> Bugs item #575770, was opened at 2002-07-01 00:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Chris Rodrigues (nokta_kanto) Assigned to: Martin v. Löwis (loewis) Summary: os.spawnv() fails with underscores Initial Comment: I'm running Python 2.2 in Windows 98. When trying to os.spawnv() a program in a path that contains an underscore, the program does not run but no error message is printed. This error happens in the dos version of Python 2.2, but not in IDLE. I detected the error by creating a DOS program that returns the recognizable value 111. If I call that file "c:\ret111.exe" and run it with the following command: os.spawnv( os.P_WAIT, progname, [progname] ) where progname is the full path and name of the program, then the function returns the value 111. If I put that file in "c:\pulse_prog\ret111.exe", and run the same command with the new value of progname, then the return value is 111 in IDLE but 0 in dos-prompt python. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-17 10:15 Message: Logged In: YES user_id=21627 I wanted to reproduce this, since I couldn't reproduce it with a program I had written on my own. As Tim has now found out, this is a bug in the program being invoked, not in Python, so closing as not-a-bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-17 05:10 Message: Logged In: YES user_id=31435 Assigned to Martin since he asked for the binary, and I don't know what he wanted to do with it. I tried it (still on Win98SE), and I do get a return value of 0 from spawnv -- sometimes. It doesn't have anything to do with whether there's an underscore in the path name for me, it has solely to do with whether the directory name has more than 8 characters. So, using: c:\pulse_prog\ret111.exe -- returns 0 c:\pulseprog\ret111.exe -- returns 0 c:\pulsepro\ret111.exe -- returns 111 More, this doesn't appear to have anything to do with Python. I get the same results with this straight C program, compiled under MSVC 6: #include <stdio.h> #include <process.h> void main() { int rc; char *prog = "c:\pulseprog\ret111.exe"; char *whatever[] = {prog, 0}; rc = _spawnv(_P_WAIT, prog, whatever); printf("return code %d\n", rc); } I have to conclude this has something to do with the compiler Chris is using. It doesn't appear to be a Python bug in any case. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 04:36 Message: Logged In: YES user_id=357491 Can anyone with Win98 test this to see if this is still a bug? ---------------------------------------------------------------------- Comment By: Chris Rodrigues (nokta_kanto) Date: 2002-08-07 00:54 Message: Logged In: YES user_id=571002 I've attached the binary file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-30 16:27 Message: Logged In: YES user_id=21627 Can you please attach the binary to this report? ---------------------------------------------------------------------- Comment By: Chris Rodrigues (nokta_kanto) Date: 2002-07-19 23:22 Message: Logged In: YES user_id=571002 Here's a screen dump of the error in progress. I don't know if it makes a difference, but ret111.exe was compiled with djgpp. C:\pulse_prog>type ret111.c int main() {return 111;} C:\pulse_prog>python Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.spawnv( os.P_WAIT, r'c:\ret111.exe', [r'c:\ret111.exe']) 111 >>> os.spawnv( os.P_WAIT, r'c:\pulse_prog\ret111.exe', [r'c:\pulse_prog\ret111.exe']) 0 >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-05 18:46 Message: Logged In: YES user_id=31435 I can't reproduce this using 2.2.1 under Win98SE. Here's a screen dump showing exactly what I did. Please show us exactly what you did. C:\pulse_prog>type ret111.c int main() { return 111; } C:\pulse_prog>cd \python22 C:\Python22>python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> prog = r"c:\pulse_prog\ret111" >>> os.spawnv(os.P_WAIT, prog, [prog]) 111 >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-05 07:52 Message: Logged In: YES user_id=21627 Can you please attach the test program to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470 From noreply@sourceforge.net Sat May 17 18:40:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 10:40:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-720908 ] datetime types don't work as bases Message-ID: <E19H5f7-0001Cj-00@sc8-sf-web4.sourceforge.net> Bugs item #720908, was opened at 2003-04-14 00:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=720908&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: datetime types don't work as bases Initial Comment: This is probably shallow. Assigned to Guido in case it's very shallow <wink>: >>> from datetime import * >>> class C(date): ... def whatever(self): ... return "oops" >>> c = C(2002, 1, 1) >>> c.whatever() Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'datetime.date' object has no attribute 'whatever' >>> type(c) <type 'datetime.date'> >>> Was reported on c.l.py. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-17 13:40 Message: Logged In: YES user_id=31435 I checked in changes (for 2.3b2) so that time, datetime, and timedelta are properly subclassable from Python too. That's all of 'em, so closing this now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 18:20 Message: Logged In: YES user_id=6380 Done; the rest is up to you! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-14 18:02 Message: Logged In: YES user_id=31435 I think the date enhancement is fine -- check it in! I'd leave off removing the basetype flag on the other types, though -- I expect we'll need to make them subclassable too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 13:26 Message: Logged In: YES user_id=6380 Here's a strawman fix. It makes 'date' a properly subclassable type, and makes all the other types (except tzinfo) non-subclassable. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-14 08:04 Message: Logged In: YES user_id=6380 Well, one shallow thing becomes obvious when you write c.__class__: it's date, not C! Back to Tim... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=720908&group_id=5470 From noreply@sourceforge.net Sun May 18 00:39:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 16:39:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-733667 ] kwargs handled incorrectly Message-ID: <E19HBGu-0006xV-00@sc8-sf-web3.sourceforge.net> Bugs item #733667, was opened at 2003-05-07 01:10 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Andrew Dalke (dalke) Assigned to: Jeremy Hylton (jhylton) Summary: kwargs handled incorrectly Initial Comment: I'm using Python2.3 (first with a1 then tested with CVS version "Python 2.3b1+ (#7, May 6 2003, 23:41:12)" compiled a few minutes ago). There's a bug in how it handles an error condition with keyword arguments. Here's a reproducible Python 2.3b1+ (#7, May 6 2003, 23:41:12) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def add(a, b): ... print "add", repr(a), repr(b) ... return a + b ... >>> add(a=3) add 'a' 3 Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in add TypeError: cannot concatenate 'str' and 'int' objects >>> The expected behaviour is what Python 2.2 does, which is >>> def add(a, b): ... return a + b ... >>> add(a=3) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: add() takes exactly 2 non-keyword arguments (1 given) >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 09:42 Message: Logged In: YES user_id=80475 Attaching a patch (actually a band-aid temporary fix). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 05:37 Message: Logged In: YES user_id=80475 Jeremy, it looks like this bug was part of your patches on 2/5/2003. CVS runs the code the day before, but not on the day after. The culprit is likely in taking the fast_function() path which bypasses the usual keyword argument handling. See ceval.c 2.348 and the related changes to sysmodule.c and ceval.h. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 04:23 Message: Logged In: YES user_id=80475 def f(a,b): print a, b def g(a,b,**kw): print a, b, kw f(c=3) # prints c 3 g(c=3) # raises correct error for non-keyword arguments. So, the restated version of the problem is that: when keyword arguments are passed to a function not defining **kw, then the keyword in interpreted as a single for the first positional argument and the keyword value as the second positional argument. Weird and bad! Reverting to earlier versions of getargs.c did not help. Likewise the dict(red=3, blue=4) patch is not the culprit. The prime suspect is now the function call optimizations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 02:54 Message: Logged In: YES user_id=80475 Ouch! This is a bad one. Bumping up the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 From noreply@sourceforge.net Sun May 18 00:43:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 16:43:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-734869 ] Lambda functions in list comprehensions Message-ID: <E19HBKQ-00074W-00@sc8-sf-web3.sourceforge.net> Bugs item #734869, was opened at 2003-05-08 16:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734869&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Thomas Finley (tomfinley) Assigned to: Jeremy Hylton (jhylton) Summary: Lambda functions in list comprehensions Initial Comment: Lambda functions that return a list built through a list comprehension used in a list comprehension cause Python to die. Example: [ (lambda a:[a**i for i in range(a+1)])(j) for j in range(5) ] You can use "map" instead of list comprehension of course (as I illustrate in my example output), so this isn't a big deal, but I think it ought to work. What follows this paragraph is an interactive session in Python, where I illustrate the workings of my lambda function to illustrate that it does work correctly in several circumstances, but not in a list comprehension. I've done this with OS X Python 2.3b1, 2.2.2, 2.2, and Solaris Python 2.2a2 with the same results. ========= Python 2.3b1 (#1, May 6 2003, 01:40:43) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> (lambda a:[a**i for i in range(a+1)])(5) [1, 5, 25, 125, 625, 3125] >>> f = lambda a:[a**i for i in range(a+1)] >>> [ f(i) for i in range(5) ] [[1], [1, 1], [1, 2, 4], [1, 3, 9, 27], [1, 4, 16, 64, 256]] >>> map(lambda a:[a**i for i in range(a+1)], range(5)) [[1], [1, 1], [1, 2, 4], [1, 3, 9, 27], [1, 4, 16, 64, 256]] >>> [ (lambda a:[a**i for i in range(a+1)])(j) for j in range(5) ] Fatal Python error: unknown scope for _[1] in <lambda>(1) in <stdin> symbols: {'a': 12, '_[2]': 2, 'range': 8, 'i': 10} locals: {'a': 0, '_[2]': 1, 'i': 2} globals: {'range': True} Abort ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:43 Message: Logged In: YES user_id=80475 I can reproduce the error on Py2.1.3, Py2.2.2, and Py2.3b1. It should probably be fixed before Py2.2.3 goes out the door next week. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-09 06:19 Message: Logged In: YES user_id=6656 Argh. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734869&group_id=5470 From noreply@sourceforge.net Sun May 18 00:43:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 16:43:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-738361 ] crash error in glob.glob; directories with brackets Message-ID: <E19HBKa-0004JC-00@sc8-sf-web4.sourceforge.net> Bugs item #738361, was opened at 2003-05-15 12:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: crash error in glob.glob; directories with brackets Initial Comment: I'm attaching a zip file containing a python file and directory structure to test this. I ran into this bug in real life work, so, as contrived as the bug test may look, it happens. I was writing a function which recurses through directories and does stuff with the files it finds. glob.glob() doesn't return any files inside a directory named [_] glob.glob() crashes on a directory named [A--_B]. I tried a few different combinations of characters inside brackets, but this was the only one I could get it to crash on. the crash happens during the regular expression compilation, as probably can be surmised by seeing the characters which cause it ( [] ). it also may be a combination of that and using \ as the directory delimiter since this is win32. File "C:\temp\globbug\bug.py", line 5, in test fs = glob.glob( path + '\*' ) File "C:\Python22\lib\glob.py", line 24, in glob list = glob(dirname) File "C:\Python22\lib\glob.py", line 37, in glob sublist = glob1(dirname, basename) File "C:\Python22\lib\glob.py", line 50, in glob1 return fnmatch.filter(names,pattern) File "C:\Python22\lib\fnmatch.py", line 47, in filter _cache[pat] = re.compile(res) File "C:\Python22\lib\sre.py", line 179, in compile return _compile(pattern, flags) File "C:\Python22\lib\sre.py", line 229, in _compile raise error, v # invalid expression sre_constants.error: bad character range ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-17 19:43 Message: Logged In: YES user_id=31435 The heart of the problem seems to be the comment in fnmatch.py's translate() docstring: """Translate a shell PATTERN to a regular expression. There is no way to quote meta-characters. """ So it looks like an undocumented design limitation. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2003-05-16 15:32 Message: Logged In: YES user_id=61663 So a co-worker pointed out that you could have directorys like mine, but say, numbered: [A--_B]1 [A--_B]2 etc say you wanted a pattern like '[A--_B]?' to get them all....that's not a valid directory, so it definitely needs to do some wildcard expansion...but it doesn't need to mess with what's inside the brackets. fnmatch probably shouldn't throw an exception in any case...regardless, we're of the opinion that the only logical way around this issue of wildcard characters in filenames is to have the programmer escape stuff manually. so r"\[A--_B]?" would be what is needed. python/glob/fnmatch can't read the programmer's mind in a pattern with wildcards which ones are supposed to be pattern or not. to take this route, fnmatch would have to be modified to recognize characters that are \-escaped, because it doesn't at the moment. or maybe that's not the best solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 14:20 Message: Logged In: YES user_id=80475 Okay. See if you can come-up with a more elegant patch that only touches the glob module. If you can see a straight-forward way to test it, then some unittests would be nice also. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2003-05-16 00:41 Message: Logged In: YES user_id=61663 brackets are valid file/dir names in unix, too. in fact, if I'm not mistaken, the only 2 characters not allowed in unix file names are / and \0. I don't see how it's not a bug if glob tries to read the files in a directory that exists and crashes (or doesn't read them). as for how it should be fixed, I have no idea. my patch isn't very elegant. btw, I just ran this on unix (after changing the \ to / in the test script) and the exact same behavior was exhibited. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 00:24 Message: Logged In: YES user_id=80475 This doesn't seem like a bug to me. Those strange names have the Unix style magic characters in them. Unfortunately, brackets are valid file/dir names in Windows. If anything were changed, I would prefer strengthening the magic character recognizer from: magic_check = re.compile('[*?[]') to something that can treat ill-formed bracket expressions as being non-magic. When posting a bug report, please avoid zip files and multiple test scripts. It is enough to include in the text of the report something like this: glob.glob('[_]/*') # fails to recognize a win directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 From noreply@sourceforge.net Sun May 18 02:29:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 18:29:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-739313 ] array.insert and negative indices Message-ID: <E19HCz6-0005Rr-00@sc8-sf-web1.sourceforge.net> Bugs item #739313, was opened at 2003-05-18 03: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=739313&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: array.insert and negative indices Initial Comment: 2.3b1 changed list.insert() so that negative indices are treated as being relative to the end of the list, but array.array.insert() still treats all negative indices as 0: >>> import array >>> a = array.array("c", "spam") >>> a.insert(-1, "x") >>> a array('c', 'xspam') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 From noreply@sourceforge.net Sun May 18 02:48:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 18:48:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-739313 ] array.insert and negative indices Message-ID: <E19HDHt-0002Ap-00@sc8-sf-web3.sourceforge.net> Bugs item #739313, was opened at 2003-05-17 21:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: array.insert and negative indices Initial Comment: 2.3b1 changed list.insert() so that negative indices are treated as being relative to the end of the list, but array.array.insert() still treats all negative indices as 0: >>> import array >>> a = array.array("c", "spam") >>> a.insert(-1, "x") >>> a array('c', 'xspam') ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-17 21:48 Message: Logged In: YES user_id=31435 Good point! I've attached the right patch. If someone else can make time to write a test/docs/NEWS, I'd appreciate it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 From noreply@sourceforge.net Sun May 18 03:00:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 19:00:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-739313 ] array.insert and negative indices Message-ID: <E19HDTB-0006KA-00@sc8-sf-web1.sourceforge.net> Bugs item #739313, was opened at 2003-05-18 03:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: array.insert and negative indices Initial Comment: 2.3b1 changed list.insert() so that negative indices are treated as being relative to the end of the list, but array.array.insert() still treats all negative indices as 0: >>> import array >>> a = array.array("c", "spam") >>> a.insert(-1, "x") >>> a array('c', 'xspam') ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:00 Message: Logged In: YES user_id=89016 OK, I'll add tests/docs/NEWS ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-18 03:48 Message: Logged In: YES user_id=31435 Good point! I've attached the right patch. If someone else can make time to write a test/docs/NEWS, I'd appreciate it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 From noreply@sourceforge.net Sun May 18 03:02:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 19:02:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-739313 ] array.insert and negative indices Message-ID: <E19HDVk-0006yo-00@sc8-sf-web4.sourceforge.net> Bugs item #739313, was opened at 2003-05-18 03:29 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: array.insert and negative indices Initial Comment: 2.3b1 changed list.insert() so that negative indices are treated as being relative to the end of the list, but array.array.insert() still treats all negative indices as 0: >>> import array >>> a = array.array("c", "spam") >>> a.insert(-1, "x") >>> a array('c', 'xspam') ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:00 Message: Logged In: YES user_id=89016 OK, I'll add tests/docs/NEWS ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-18 03:48 Message: Logged In: YES user_id=31435 Good point! I've attached the right patch. If someone else can make time to write a test/docs/NEWS, I'd appreciate it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 From noreply@sourceforge.net Sun May 18 04:17:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 20:17:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-739313 ] array.insert and negative indices Message-ID: <E19HEgF-00069w-00@sc8-sf-web2.sourceforge.net> Bugs item #739313, was opened at 2003-05-18 03:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: array.insert and negative indices Initial Comment: 2.3b1 changed list.insert() so that negative indices are treated as being relative to the end of the list, but array.array.insert() still treats all negative indices as 0: >>> import array >>> a = array.array("c", "spam") >>> a.insert(-1, "x") >>> a array('c', 'xspam') ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 05:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.22 Doc/lib/libarray.tex 1.36 Misc/NEWS 1.769 Modules/arraymodule.c 2.89 Should the docstring be updated too? It seems to be rather terse. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:00 Message: Logged In: YES user_id=89016 OK, I'll add tests/docs/NEWS ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-18 03:48 Message: Logged In: YES user_id=31435 Good point! I've attached the right patch. If someone else can make time to write a test/docs/NEWS, I'd appreciate it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 From noreply@sourceforge.net Sun May 18 05:27:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 21:27:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-739313 ] array.insert and negative indices Message-ID: <E19HFlG-0007jw-00@sc8-sf-web2.sourceforge.net> Bugs item #739313, was opened at 2003-05-17 21:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: array.insert and negative indices Initial Comment: 2.3b1 changed list.insert() so that negative indices are treated as being relative to the end of the list, but array.array.insert() still treats all negative indices as 0: >>> import array >>> a = array.array("c", "spam") >>> a.insert(-1, "x") >>> a array('c', 'xspam') ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-18 00:27 Message: Logged In: YES user_id=31435 Well, Guido would probably shrink the docstring, by taking the information-free "a new item" out of it. That would make it closer to the list.insert() docstring, BTW. The unenforced rule is that docstrings are mnemonic, and the real docs are in the manuals. I think it says enough as-is. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 23:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.22 Doc/lib/libarray.tex 1.36 Misc/NEWS 1.769 Modules/arraymodule.c 2.89 Should the docstring be updated too? It seems to be rather terse. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-17 22:00 Message: Logged In: YES user_id=89016 OK, I'll add tests/docs/NEWS ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-17 21:48 Message: Logged In: YES user_id=31435 Good point! I've attached the right patch. If someone else can make time to write a test/docs/NEWS, I'd appreciate it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 From noreply@sourceforge.net Sun May 18 13:10:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 05:10:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-739424 ] Python2.3b1 install problems on Linux Message-ID: <E19HMzI-0007FK-00@sc8-sf-web4.sourceforge.net> Bugs item #739424, was opened at 2003-05-18 05:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 install problems on Linux Initial Comment: I'm running Red Hat Linux 8.0, patches fully up to date, with the latest tcl/tk packages installed. Python2.2.1 is running fine, including Tkinter and IDLE. Followed the standard install procedure for Python-2.3.b1 tarball, and Tkinter is now broken. Can't install IDLE. ./configure and make ran OK. ~/Python-2.3b1> make test 227 tests OK 26 skipped 1 unexpected skip on linux2: test_bz2 No module named bz2 ~/Python-2.3b1> make install ... building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -I/usr/X11R6/include -I. -I/home/macquigg/Python-2.3b1/./Include -I/usr/local/include -I/home/macquigg/Python-2.3b1/Include -I/home/macquigg/Python-2.3b1 -c /home/macquigg/Python-2.3b1/Modules/_tkinter.c -o build/temp.linux-i686-2.3/_tkinter.o cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" /usr/include/tk.h:597: parse error before "Bool" ... many more of these parse errors ... ==> Cannot find "Xlib.h" anywhere under /usr/include, /usr/X11R6, or in the Python-2.3b1 distribution. As far as I know, the X11 files have not been altered. Python 2.2.1 still runs OK. Here are the versions on the tcl/tk packages recently downloaded from RedHat. -rw-rw-r-- 1 macquigg macquigg 1570466 May 10 11:36 tcl-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 460160 May 10 13:47 tix-8.2.0b1-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 1390929 May 10 11:40 tk-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 265427 Apr 25 04:54 tkinter-2.2.1-17.i386.rpm More details in the attached logfile. I'll try to keep this configuration together for debugging. - Dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 From noreply@sourceforge.net Sun May 18 13:31:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 05:31:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-444514 ] raw-unicode-escape codec fails roundtrip Message-ID: <E19HNKP-0007xg-00@sc8-sf-web1.sourceforge.net> Bugs item #444514, was opened at 2001-07-25 18:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 Category: Unicode Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Martin v. Löwis (loewis) Summary: raw-unicode-escape codec fails roundtrip Initial Comment: On wide Python builds, the raw-unicode-escape codec fails the round-trip for non-BMP code points. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-18 14:31 Message: Logged In: YES user_id=21627 This is fixed in test_unicode.py 1.84 unicodeobject.c 2.188 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 01:51 Message: Logged In: YES user_id=357491 OK, I am reassigning to Martin as per MA's suggestion. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-05-12 11:28 Message: Logged In: YES user_id=38388 I haven't done anything in that direction and don't have the time to do now, so feel free to assign the bug report to someone else, e.g. Martin who has done most of the wide Unicode support. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 01:55 Message: Logged In: YES user_id=357491 Marc-Andre, is this bug still unresolved? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 12:47 Message: Logged In: YES user_id=38388 I'll look into this after I'm back from vacation on the 10.09. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 From noreply@sourceforge.net Sun May 18 13:38:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 05:38:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-739313 ] array.insert and negative indices Message-ID: <E19HNRC-0008Db-00@sc8-sf-web4.sourceforge.net> Bugs item #739313, was opened at 2003-05-18 03:29 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: array.insert and negative indices Initial Comment: 2.3b1 changed list.insert() so that negative indices are treated as being relative to the end of the list, but array.array.insert() still treats all negative indices as 0: >>> import array >>> a = array.array("c", "spam") >>> a.insert(-1, "x") >>> a array('c', 'xspam') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-18 06:27 Message: Logged In: YES user_id=31435 Well, Guido would probably shrink the docstring, by taking the information-free "a new item" out of it. That would make it closer to the list.insert() docstring, BTW. The unenforced rule is that docstrings are mnemonic, and the real docs are in the manuals. I think it says enough as-is. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 05:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.22 Doc/lib/libarray.tex 1.36 Misc/NEWS 1.769 Modules/arraymodule.c 2.89 Should the docstring be updated too? It seems to be rather terse. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-05-18 04:00 Message: Logged In: YES user_id=89016 OK, I'll add tests/docs/NEWS ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-18 03:48 Message: Logged In: YES user_id=31435 Good point! I've attached the right patch. If someone else can make time to write a test/docs/NEWS, I'd appreciate it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739313&group_id=5470 From noreply@sourceforge.net Sun May 18 14:46:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 06:46:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-736659 ] markupbase parse_declaration cannot recognize comments Message-ID: <E19HOV5-0006Gg-00@sc8-sf-web2.sourceforge.net> Bugs item #736659, was opened at 2003-05-12 16:34 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736659&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: markupbase parse_declaration cannot recognize comments Initial Comment: In markupbase class parser method parse_declaration It verfies that the first two characters are "<!" Then it returns -1 if the next character is "-". After that, it checks to see if the next two characters are "--", but if they were, it would already have returned. Solution: Check for comments before checking for a short buffer. if rawdata[j:j+1] == '--': #comment # Locate --.*-- as the body of the comment return self.parse_comment(i) if rawdata[j:j+1] in ("-", ""): # Start of comment followed by buffer # boundary, or just a buffer boundary. return -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736659&group_id=5470 From noreply@sourceforge.net Sun May 18 21:10:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 13:10:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: <E19HUU0-0007MS-00@sc8-sf-web1.sourceforge.net> Bugs item #570300, was opened at 2002-06-18 04:24 Message generated for change (Comment added) made by amitar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amit Aronovitch (amitar) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- >Comment By: Amit Aronovitch (amitar) Date: 2003-05-18 23:10 Message: Logged In: YES user_id=564711 Sorry - seems like I forgot most basic step in prob- reporting - the "howtorepeat" :-) - so here it comes: How to repeat: ---------------------- (as I said - you need unix & symlinks to see this happening): ~> mkdir test ~> setenv PYTHONPATH ~/test ~> cat >test/test_mod.py "module doc" def blah(): "hello" pass ^D ~> python >> import test_mod >> help(test_mod) >> ^D [ Prints help - so far so good - no problem - but see now] ~> ln -s test test2 ~> setenv PYTHONPATH test2 ~> python >> import test_mod >> help(test_mod) [ Now the help shows up without the help of the blah function] Relating the example to my explanations above: ------------------------------------------------------------------------ The help of the blah() function is filtered out, because "inspect" takes "~/test/test_mod.pyc" as it's filename, and "~/test1/test_mod.pyc" as the module's filename. It can't tell that these are the same file (see details in my "Analysis" section above). True, this messing up with symlinks and PYTHONPATH is a bit ugly, but this is just to demonstrate the problem. The system where I noticed it is quite complex, with disks shared (automounted) across several platforms, and it needs a few symlinks to make things easyer to maintain. As I explained, I think that few little changes in modules such as "inspect" and "os" can make them identify files better in the presence of links. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 05:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply@sourceforge.net Sun May 18 21:12:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 13:12:22 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-714469 ] Easy tutorial printing should be possible Message-ID: <E19HUW6-0007SV-00@sc8-sf-web1.sourceforge.net> Feature Requests item #714469, was opened at 2003-04-03 11:01 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470 Category: Documentation Group: None >Status: Open Resolution: Invalid Priority: 5 Submitted By: Joost Jacob (wspace) Assigned to: Nobody/Anonymous (nobody) Summary: Easy tutorial printing should be possible Initial Comment: I wanted to print the Python Tutorial by Guido for a colleague who might be interested in Python. But this was not easy since it is distributed over a 18 different html files! So now he has something looking bad because page numbers restart at every section. I didn't have the time to think of a better solution: I wanted to give a printed tutorial fast. So the request is this: make the tutorial available in ONE html file so anybody can print it nicely with correct pagenumbers etc. from their browser. This could also be interesting for the other documentation? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-18 22:12 Message: Logged In: YES user_id=45365 Raymond, I think that the real complaint is "you cannot print the tutorial without downloading the full documentation set". I think this is a valid complaint: it's a bit silly to have to download and unpack the whole set only to print a single document. My suggestion would be to add a (pdf) link to each of the lines that point to the various HTML documentation sections. If you really don't agree feel free to set the state to closed/invalid again. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 19:57 Message: Logged In: YES user_id=80475 The PDF and PostScript formats are better suited to printing out booklets. Let us know if these links meet your needs: http://www.python.org/doc/current/download.html ---------------------------------------------------------------------- Comment By: Joost Jacob (wspace) Date: 2003-04-03 11:54 Message: Logged In: YES user_id=697662 Jack Jansen mentions availability of PDF files, but I did not find those on the Python web site when I was (in a hurry) looking for the tutorial. Also he mentions "Letter" or "A4" variations, but this is one of the reasons I think one HTML file would be best for each document: the users' browser can print that to postscript or send it directly to a printer with all the users' favorite options. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-03 11:44 Message: Logged In: YES user_id=45365 The tutorial is also available in PDF, but at the moment only if you download an archive containing the full documentation set (on the doc/current/download.html page). Maybe it is a good idea to make the PDFs available separately too? The letter variation is probably best, non-americans are more used to letter than americans to A4, I guess... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470 From noreply@sourceforge.net Sun May 18 21:57:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 13:57:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-739424 ] Python2.3b1 install problems on Linux Message-ID: <E19HVDp-0001GV-00@sc8-sf-web4.sourceforge.net> Bugs item #739424, was opened at 2003-05-18 08:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 install problems on Linux Initial Comment: I'm running Red Hat Linux 8.0, patches fully up to date, with the latest tcl/tk packages installed. Python2.2.1 is running fine, including Tkinter and IDLE. Followed the standard install procedure for Python-2.3.b1 tarball, and Tkinter is now broken. Can't install IDLE. ./configure and make ran OK. ~/Python-2.3b1> make test 227 tests OK 26 skipped 1 unexpected skip on linux2: test_bz2 No module named bz2 ~/Python-2.3b1> make install ... building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -I/usr/X11R6/include -I. -I/home/macquigg/Python-2.3b1/./Include -I/usr/local/include -I/home/macquigg/Python-2.3b1/Include -I/home/macquigg/Python-2.3b1 -c /home/macquigg/Python-2.3b1/Modules/_tkinter.c -o build/temp.linux-i686-2.3/_tkinter.o cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" /usr/include/tk.h:597: parse error before "Bool" ... many more of these parse errors ... ==> Cannot find "Xlib.h" anywhere under /usr/include, /usr/X11R6, or in the Python-2.3b1 distribution. As far as I know, the X11 files have not been altered. Python 2.2.1 still runs OK. Here are the versions on the tcl/tk packages recently downloaded from RedHat. -rw-rw-r-- 1 macquigg macquigg 1570466 May 10 11:36 tcl-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 460160 May 10 13:47 tix-8.2.0b1-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 1390929 May 10 11:40 tk-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 265427 Apr 25 04:54 tkinter-2.2.1-17.i386.rpm More details in the attached logfile. I'll try to keep this configuration together for debugging. - Dave ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-18 16:57 Message: Logged In: YES user_id=33168 You will need the Xlib headers installed to build Tkinter. The RPM package which contains the headers is probably something like XFree86-devel-4-3.0-2. Try installing that package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 From noreply@sourceforge.net Sun May 18 22:05:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 14:05:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-560064 ] inconsistent behavior of __getslice__ Message-ID: <E19HVL2-0000mT-00@sc8-sf-web1.sourceforge.net> Bugs item #560064, was opened at 2002-05-24 07:59 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cesar Douady (douady) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistent behavior of __getslice__ Initial Comment: The following trace shows what I mean: >>> help(str.__getslice__) Help on wrapper_descriptor: __getslice__(...) x.__getslice__(i, j) <==> x[i:j] >>> 'ab'[-1] 'b' >>> 'ab'.__getitem__(-1) 'b' >>> 'ab'[-2:-1] 'a' >>> 'ab'.__getslice__(-2,-1) '' that is, __getslice__ does not add the length of the sequence to its arguments when they are negative as indexing with [:] does. This contradicts the docstring which says __getslice__ is equivalent to indexing. The same behavior applies to lists. Note that __getitem__ does it right. This bug may be linked to bug 473985 ('str, __getitem__ and slices') but should be much easier to fix. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 17:05 Message: Logged In: YES user_id=6380 Yes, please fix the docstring. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 22:19 Message: Logged In: YES user_id=357491 If the docstring fix is still the best way to fix this I am willing to make the change. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 15:23 Message: Logged In: YES user_id=6380 This should NOT be fixed this way, Raymond! The docs are (subtly) wrong. For historical reasons, __getslice__ expects the Python VM to do the adjustment of negative indices. If you did another adjustment inside getslice, certain indices would start behaving differently (e.g. s[:-5] where len(s)==3). Maybe the docstring should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 08:58 Message: Logged In: YES user_id=80475 Tim, I attached a tiny patch which fixes the behavior for strings. I've also tried out the same change in listobject.c and unicodeobject.c. Is this the right this to do or are there more subtleties to this than meet the eye? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470 From noreply@sourceforge.net Sun May 18 22:05:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 14:05:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-576990 ] inheriting from property and docstrings Message-ID: <E19HVLb-0000nL-00@sc8-sf-web1.sourceforge.net> Bugs item #576990, was opened at 2002-07-03 10:42 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: Accepted Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Guido van Rossum (gvanrossum) Summary: inheriting from property and docstrings Initial Comment: If I inherit from property, and try to initialize a derived property object, the doc string doesn't get set. This bug was introduced in 2.2.1, and is present in 2.3a0: Compare: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ hi and, Python 2.2.1 (#1, Jun 16 2002, 16:19:48) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ None There is no problem with the getter/setter functions passed to the constructor. i.e.: myprop(f,g,h,None) works identical in 2.2 and 2.2.1 Good luck, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 17:05 Message: Logged In: YES user_id=6380 Yes, you remember correctly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 22:39 Message: Logged In: YES user_id=357491 I vaguely remember this coming on up on python-dev and it being said that this would not get fixed. Am I remembering correctly? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-24 13:01 Message: Logged In: YES user_id=6380 The problem is that class myprop has a __doc__ in its class __dict__ that is the docstring for myprop, or None if that class has no docstring. The march through the MRO looking for an instance attribute descriptor finds this before it would ever get to the property class, so effectively a __doc__ property is not inherited. The simplest workaround I found is this: class myprop(property): __doc__ = property.__dict__['__doc__'] (__doc__ = property.__doc__ does not do the right thing, it gets the property class's docstring rather than the descriptor.) This is a mess. I'll have to think about whether it's possible at all to fix it without breaking something else. I'll also have to think about whether it's worth it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-24 09:12 Message: Logged In: YES user_id=11105 Ups, forget my patch. Nothing works, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-24 09:06 Message: Logged In: YES user_id=11105 The attached simple fix (descrobj.diff) fixes the problem for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-24 08:43 Message: Logged In: YES user_id=6380 OK, I'll have a look. We've have numerous hacks upon hacks to get __doc__ to behave right. I don't know if it is within my powers to fix this without breaking other things. But if it is, I'll try to fix it in 2.2.1 as well as 2.3. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-09-09 06:49 Message: Logged In: YES user_id=302601 To give a usage example: (because rhettinger thought this was a very strange use of properties, and, for all I know, he may be right) >>> class typed_property(property): ... def __init__(self, tp, doc): ... def getter(inst): ... return inst.__dict__[self] ... def setter(inst, val): ... if not isinstance(val, tp): ... raise TypeError ... inst.__dict__[self] = val ... property.__init__(self, getter, setter, ... None, doc) ... >>> class A(object): ... a = typed_property(int, 'a prop') ... >>> inst = A() >>> inst.a = 1 >>> print inst.a 1 >>> inst.a = 'a' Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 7, in setter TypeError >>> A.a.__doc__ 'a prop' The last only works in 2.2, and then only if typed_property itself has no doc string ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 18:11 Message: Logged In: YES user_id=80475 Okay, now I see what you're trying to do. Still, it the strangest use of property that I've seen to-date. Re-opening the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 17:55 Message: Logged In: YES user_id=80475 I think this is based on a misunderstanding of how to use property. Instead of inheriting from it, you use it as a function call in a new-style class (derived from object): This works fine in versions from 2.2 upto 2.3a: >>> class Myprop(object): a = property(None,None,None,'a sample docstring') >>> Myprop.a.__doc__ 'a sample docstring' Marking as invalid and closing. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-09 07:52 Message: Logged In: YES user_id=302601 I think I found the problem, Compare: >>> property.__doc__ 'property(fget=None,.... # the doc string and >>> property.__dict__['__doc__'] <member '__doc__' of 'property' objects> Note that property.__doc__ and property.__dict__['__doc__'] are not the same. Python will go out of its way to prevent this weird situation in user derived classes., 1. type_new(name, bases, attrs) will copy attrs to new_tp.tp_dict, and will also copy attrs['__doc__'] to tp.tp_doc 2. PyType_Ready(tp) will copy tp.tp_doc to tp.tp_dict['__doc__'] if tp.tp_dict['__doc__'] is undefined This guarantees that tp.tp_dict['__doc__'] will exist, usually copying tp.tp_doc, and shadowing property.tp_dict['__doc__'] if tp is derived from property The solution seems to be: 1. In type_new(): if possible copy attr['__doc__'] to tp.tp_doc, and delete __doc__ from attr (to prevent ending up in tp_dict) 2. in PyType_Ready(): don't copy tp.tp_doc to tp_dict['__doc__'] These two steps make sure that, tp_dict['__doc__'] no longer shadows properties.tp_dict['__doc__']. Unfortunately, this means that tp.__doc__ doesn't generally return the docstrings for user-defined types. Therefore: 3. in type_get_doc(): return tp.tp_doc also for heap types. The result of this will be: 1. properties will be subclassable again. (good) 2. __doc__ string become read-only attributes (bad??) 3. test cases in test_descr that assume that instance.__dict__['__doc__'] exists, will fail 4. a weird test_failure in test_module.py Patches for this modification are attached, except for (test_module.py), which I don't understand. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-08 08:23 Message: Logged In: YES user_id=302601 Some more details: In fact 2.2.1 is consistently wrong, whereas 2.2 is inconsistently right ;), compare: Python 2.2.1 (#20, Jul 8 2002, 13:25:14) [GCC 3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ None >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string and Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ Hi there >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string So, in 2.2.1 myprop(...).__doc__ will allways return myprop.__doc__. In 2.2 myprop.__doc__ will return the instance's __doc__, iff myprop.__doc__ is None. For the record: I was expecting 'Hi there' (i.e. obj->prop_doc), as in: >>> property(None, None, None, 'Hi there').__doc__ 'Hi there' Hope this helps, Roeland ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 From noreply@sourceforge.net Sun May 18 22:08:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 14:08:04 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-714469 ] Easy tutorial printing should be possible Message-ID: <E19HVO0-000558-00@sc8-sf-web2.sourceforge.net> Feature Requests item #714469, was opened at 2003-04-03 11:01 Message generated for change (Comment added) made by wspace You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: Joost Jacob (wspace) Assigned to: Nobody/Anonymous (nobody) Summary: Easy tutorial printing should be possible Initial Comment: I wanted to print the Python Tutorial by Guido for a colleague who might be interested in Python. But this was not easy since it is distributed over a 18 different html files! So now he has something looking bad because page numbers restart at every section. I didn't have the time to think of a better solution: I wanted to give a printed tutorial fast. So the request is this: make the tutorial available in ONE html file so anybody can print it nicely with correct pagenumbers etc. from their browser. This could also be interesting for the other documentation? ---------------------------------------------------------------------- >Comment By: Joost Jacob (wspace) Date: 2003-05-18 23:08 Message: Logged In: YES user_id=697662 Ah...latests messages are listed high. I didn't know and was reading the bottom (nothing new). I am the Original Poster (OP) and Jack is right about the OP's "real complaint". I wanted to print the tutorial fast, from HTML or PDF preferably. I would like to add I do not like the word complaint for this, Python is open source, and I am very happy with any docs there are. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-18 22:12 Message: Logged In: YES user_id=45365 Raymond, I think that the real complaint is "you cannot print the tutorial without downloading the full documentation set". I think this is a valid complaint: it's a bit silly to have to download and unpack the whole set only to print a single document. My suggestion would be to add a (pdf) link to each of the lines that point to the various HTML documentation sections. If you really don't agree feel free to set the state to closed/invalid again. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-12 19:57 Message: Logged In: YES user_id=80475 The PDF and PostScript formats are better suited to printing out booklets. Let us know if these links meet your needs: http://www.python.org/doc/current/download.html ---------------------------------------------------------------------- Comment By: Joost Jacob (wspace) Date: 2003-04-03 11:54 Message: Logged In: YES user_id=697662 Jack Jansen mentions availability of PDF files, but I did not find those on the Python web site when I was (in a hurry) looking for the tutorial. Also he mentions "Letter" or "A4" variations, but this is one of the reasons I think one HTML file would be best for each document: the users' browser can print that to postscript or send it directly to a printer with all the users' favorite options. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-03 11:44 Message: Logged In: YES user_id=45365 The tutorial is also available in PDF, but at the moment only if you download an archive containing the full documentation set (on the doc/current/download.html page). Maybe it is a good idea to make the PDFs available separately too? The letter variation is probably best, non-americans are more used to letter than americans to A4, I guess... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=714469&group_id=5470 From noreply@sourceforge.net Sun May 18 22:22:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 14:22:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: <E19HVbo-0001KS-00@sc8-sf-web1.sourceforge.net> Bugs item #729317, was opened at 2003-04-29 05:41 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) >Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a <type 'float'> and _tkinter.TCL_VERSION is a <type 'str'> Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-18 23:22 Message: Logged In: YES user_id=45365 Martin, I'm assigning back to you, because I'm out of my water here. I discussed this problem with the MacTcl people, and it seems that what was checked in in _tkinter.c for patch 518625 is not correct: if something is initialized as a string in Tcl and then some code accesses it as a float the internal float representation will be created automatically. In other words: the FromObj() code attempts to graft Python semantics on Tcl objects, which is prone to obscure errors. Here are some excerpts from relevant mail messages: ------------- >From Jim Ingham: tcl_version is created as a string variable with the value "8.2". If somebody tried to do some math with it (like evaluate expr $tcl_version <= 8.4 or something) then Tcl would set the internal representation to a float. I don't see any place where we are doing that, but maybe your Tkinter code does that to check something on Mac OS X? Anyway that would not be an error on Tcl's part. If you want tcl_version in Python explicitly as a string, you need to make sure the string representation exists, and then get the variable as a string. You can't rely on their being or not being any particular internal representation. ------------------ And from Benjamin Riefenstahl: Well, somebody may already have told you that, but that's not how Tcl works. In Tcl *all* values are strings. You use Tcl_GetStringFromObj() to get that value. That's it. If you want a floating point, you explicitly *convert* by using Tcl_GetDoubleFromObj(). Everything you see related to "types" is just internal speed optimizations to avoid double conversions. These internal representations come and go at the whim of the implementation. Accessing these infos without the official APIs will lead to errors and inconsistent behaviour, as you have seen. The details of the behaviour will also quite likely change from Tcl version to Tcl version. --------------- ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:29 Message: Logged In: YES user_id=21627 This seems to happen only in the Mac version of Tcl. I can't reproduce it on Linux or Windows, and I can't see anything in the Tcl sources that may causing it. tcl_version is set in generic/tclBasic.c using Tcl_SetVar, i.e. as a string. It is never referred-to in the Tcl sources, except for being returned from 'info tclversion'. So I can't see why it would ever be changed to a floating point object. Perhaps the Mac is not using the original Tcl source code? Assigning to Jack for further investigation. ---------------------------------------------------------------------- Comment By: Larry Bugbee (thunderbug) Date: 2003-05-10 04:44 Message: Logged In: YES user_id=10953 Several of us have encountered this. Personally, I have seen this with Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2. ...and with Tcl/Tk 8.4.2. ...and under 10.2.5 and 2.3b1. I've tried several combinations. My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/ python/mac/ . I hope this helps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 00:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 07:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Sun May 18 23:20:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 15:20:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-560064 ] inconsistent behavior of __getslice__ Message-ID: <E19HWVx-0007O9-00@sc8-sf-web2.sourceforge.net> Bugs item #560064, was opened at 2002-05-24 04:59 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cesar Douady (douady) >Assigned to: Brett Cannon (bcannon) Summary: inconsistent behavior of __getslice__ Initial Comment: The following trace shows what I mean: >>> help(str.__getslice__) Help on wrapper_descriptor: __getslice__(...) x.__getslice__(i, j) <==> x[i:j] >>> 'ab'[-1] 'b' >>> 'ab'.__getitem__(-1) 'b' >>> 'ab'[-2:-1] 'a' >>> 'ab'.__getslice__(-2,-1) '' that is, __getslice__ does not add the length of the sequence to its arguments when they are negative as indexing with [:] does. This contradicts the docstring which says __getslice__ is equivalent to indexing. The same behavior applies to lists. Note that __getitem__ does it right. This bug may be linked to bug 473985 ('str, __getitem__ and slices') but should be much easier to fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 14:05 Message: Logged In: YES user_id=6380 Yes, please fix the docstring. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:19 Message: Logged In: YES user_id=357491 If the docstring fix is still the best way to fix this I am willing to make the change. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 12:23 Message: Logged In: YES user_id=6380 This should NOT be fixed this way, Raymond! The docs are (subtly) wrong. For historical reasons, __getslice__ expects the Python VM to do the adjustment of negative indices. If you did another adjustment inside getslice, certain indices would start behaving differently (e.g. s[:-5] where len(s)==3). Maybe the docstring should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 05:58 Message: Logged In: YES user_id=80475 Tim, I attached a tiny patch which fixes the behavior for strings. I've also tried out the same change in listobject.c and unicodeobject.c. Is this the right this to do or are there more subtleties to this than meet the eye? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470 From noreply@sourceforge.net Sun May 18 23:21:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 15:21:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-576990 ] inheriting from property and docstrings Message-ID: <E19HWXP-0007S5-00@sc8-sf-web2.sourceforge.net> Bugs item #576990, was opened at 2002-07-03 07:42 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Guido van Rossum (gvanrossum) Summary: inheriting from property and docstrings Initial Comment: If I inherit from property, and try to initialize a derived property object, the doc string doesn't get set. This bug was introduced in 2.2.1, and is present in 2.3a0: Compare: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ hi and, Python 2.2.1 (#1, Jun 16 2002, 16:19:48) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> a = myprop(None, None, None, 'hi') >>> print a.__doc__ None There is no problem with the getter/setter functions passed to the constructor. i.e.: myprop(f,g,h,None) works identical in 2.2 and 2.2.1 Good luck, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-18 15:21 Message: Logged In: YES user_id=357491 Since Guido said I remembered correctly I am closing this as "won't fix". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 14:05 Message: Logged In: YES user_id=6380 Yes, you remember correctly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:39 Message: Logged In: YES user_id=357491 I vaguely remember this coming on up on python-dev and it being said that this would not get fixed. Am I remembering correctly? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-24 10:01 Message: Logged In: YES user_id=6380 The problem is that class myprop has a __doc__ in its class __dict__ that is the docstring for myprop, or None if that class has no docstring. The march through the MRO looking for an instance attribute descriptor finds this before it would ever get to the property class, so effectively a __doc__ property is not inherited. The simplest workaround I found is this: class myprop(property): __doc__ = property.__dict__['__doc__'] (__doc__ = property.__doc__ does not do the right thing, it gets the property class's docstring rather than the descriptor.) This is a mess. I'll have to think about whether it's possible at all to fix it without breaking something else. I'll also have to think about whether it's worth it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-24 06:12 Message: Logged In: YES user_id=11105 Ups, forget my patch. Nothing works, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-24 06:06 Message: Logged In: YES user_id=11105 The attached simple fix (descrobj.diff) fixes the problem for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-24 05:43 Message: Logged In: YES user_id=6380 OK, I'll have a look. We've have numerous hacks upon hacks to get __doc__ to behave right. I don't know if it is within my powers to fix this without breaking other things. But if it is, I'll try to fix it in 2.2.1 as well as 2.3. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-09-09 03:49 Message: Logged In: YES user_id=302601 To give a usage example: (because rhettinger thought this was a very strange use of properties, and, for all I know, he may be right) >>> class typed_property(property): ... def __init__(self, tp, doc): ... def getter(inst): ... return inst.__dict__[self] ... def setter(inst, val): ... if not isinstance(val, tp): ... raise TypeError ... inst.__dict__[self] = val ... property.__init__(self, getter, setter, ... None, doc) ... >>> class A(object): ... a = typed_property(int, 'a prop') ... >>> inst = A() >>> inst.a = 1 >>> print inst.a 1 >>> inst.a = 'a' Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 7, in setter TypeError >>> A.a.__doc__ 'a prop' The last only works in 2.2, and then only if typed_property itself has no doc string ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 15:11 Message: Logged In: YES user_id=80475 Okay, now I see what you're trying to do. Still, it the strangest use of property that I've seen to-date. Re-opening the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 14:55 Message: Logged In: YES user_id=80475 I think this is based on a misunderstanding of how to use property. Instead of inheriting from it, you use it as a function call in a new-style class (derived from object): This works fine in versions from 2.2 upto 2.3a: >>> class Myprop(object): a = property(None,None,None,'a sample docstring') >>> Myprop.a.__doc__ 'a sample docstring' Marking as invalid and closing. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-09 04:52 Message: Logged In: YES user_id=302601 I think I found the problem, Compare: >>> property.__doc__ 'property(fget=None,.... # the doc string and >>> property.__dict__['__doc__'] <member '__doc__' of 'property' objects> Note that property.__doc__ and property.__dict__['__doc__'] are not the same. Python will go out of its way to prevent this weird situation in user derived classes., 1. type_new(name, bases, attrs) will copy attrs to new_tp.tp_dict, and will also copy attrs['__doc__'] to tp.tp_doc 2. PyType_Ready(tp) will copy tp.tp_doc to tp.tp_dict['__doc__'] if tp.tp_dict['__doc__'] is undefined This guarantees that tp.tp_dict['__doc__'] will exist, usually copying tp.tp_doc, and shadowing property.tp_dict['__doc__'] if tp is derived from property The solution seems to be: 1. In type_new(): if possible copy attr['__doc__'] to tp.tp_doc, and delete __doc__ from attr (to prevent ending up in tp_dict) 2. in PyType_Ready(): don't copy tp.tp_doc to tp_dict['__doc__'] These two steps make sure that, tp_dict['__doc__'] no longer shadows properties.tp_dict['__doc__']. Unfortunately, this means that tp.__doc__ doesn't generally return the docstrings for user-defined types. Therefore: 3. in type_get_doc(): return tp.tp_doc also for heap types. The result of this will be: 1. properties will be subclassable again. (good) 2. __doc__ string become read-only attributes (bad??) 3. test cases in test_descr that assume that instance.__dict__['__doc__'] exists, will fail 4. a weird test_failure in test_module.py Patches for this modification are attached, except for (test_module.py), which I don't understand. ---------------------------------------------------------------------- Comment By: Roeland Rengelink (rengelink) Date: 2002-07-08 05:23 Message: Logged In: YES user_id=302601 Some more details: In fact 2.2.1 is consistently wrong, whereas 2.2 is inconsistently right ;), compare: Python 2.2.1 (#20, Jul 8 2002, 13:25:14) [GCC 3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ None >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string and Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class myprop(property):pass ... >>> class yourprop(property): ... "A doc string" ... >>> print myprop(None, None, None, 'Hi there').__doc__ Hi there >>> print yourprop(None, None, None, 'Hi there').__doc__ A doc string So, in 2.2.1 myprop(...).__doc__ will allways return myprop.__doc__. In 2.2 myprop.__doc__ will return the instance's __doc__, iff myprop.__doc__ is None. For the record: I was expecting 'Hi there' (i.e. obj->prop_doc), as in: >>> property(None, None, None, 'Hi there').__doc__ 'Hi there' Hope this helps, Roeland ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576990&group_id=5470 From noreply@sourceforge.net Mon May 19 02:33:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 18:33:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-738617 ] On Windows, os.listdir() throws incorrect exception Message-ID: <E19HZWl-0004HW-00@sc8-sf-web2.sourceforge.net> Bugs item #738617, was opened at 2003-05-15 22:11 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738617&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Thompson (mikethompson) Assigned to: Nobody/Anonymous (nobody) Summary: On Windows, os.listdir() throws incorrect exception Initial Comment: 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 os >>> os.listdir('c:\IMPOSSIBLE') Traceback (most recent call last): File "<stdin>", line 2, in ? WindowsError: [Errno 3] The system cannot find the path specified: 'c:\IMPOSSIBLE/*.*' This is the wrong exception I would have thought. AIUI, WindowsError is thrown for uniquely Windows types of problems. Path not found is not unique to Windows. I would have expected an os.error exception to have been thrown together with an code of errno.ENOENT. This is what happens if I try to open() a non existent file. (Caution: I'm a python newbie and I could easily have missed something here -- If so sorry to waste your time) The deadly part about this bug is that WindowsError subclasses os.error, just the code changes (3 instead of 2). So my "except os.error" worked to catch the exception ... just the error code seemed wrong. Took be ages to figure it all out. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-05-18 20:33 Message: Logged In: YES user_id=2772 Python faithfully relays to you the information returned by the OS in these cases. I don't think it's planned for Python to try to rationalize the various errno/GetLastError() values based on what it thinks the actual error must have been. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738617&group_id=5470 From noreply@sourceforge.net Mon May 19 02:53:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 18:53:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-738617 ] On Windows, os.listdir() throws incorrect exception Message-ID: <E19HZq9-0000eo-00@sc8-sf-web1.sourceforge.net> Bugs item #738617, was opened at 2003-05-16 13:11 Message generated for change (Comment added) made by mikethompson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738617&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Thompson (mikethompson) Assigned to: Nobody/Anonymous (nobody) Summary: On Windows, os.listdir() throws incorrect exception Initial Comment: 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 os >>> os.listdir('c:\IMPOSSIBLE') Traceback (most recent call last): File "<stdin>", line 2, in ? WindowsError: [Errno 3] The system cannot find the path specified: 'c:\IMPOSSIBLE/*.*' This is the wrong exception I would have thought. AIUI, WindowsError is thrown for uniquely Windows types of problems. Path not found is not unique to Windows. I would have expected an os.error exception to have been thrown together with an code of errno.ENOENT. This is what happens if I try to open() a non existent file. (Caution: I'm a python newbie and I could easily have missed something here -- If so sorry to waste your time) The deadly part about this bug is that WindowsError subclasses os.error, just the code changes (3 instead of 2). So my "except os.error" worked to catch the exception ... just the error code seemed wrong. Took be ages to figure it all out. ---------------------------------------------------------------------- >Comment By: Mike Thompson (mikethompson) Date: 2003-05-19 11:53 Message: Logged In: YES user_id=630223 Yet, if I try to open() a non existent file, this mapping to a generic Python exception DOES occur (exception is os.error, code is errno.ENOENT) And just as well it does too because otherwise cross-platform coding would be difficult. Now, if its good enough for open(), why not for os.listdir()? >From the documentation, I got the impression that WindowError gets used for Windows specific problems for which generic cross-platform handling makes no sense, which is why WindowsError simply wraps errno/GetLastError () and sub-classes the standard exception. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-05-19 11:33 Message: Logged In: YES user_id=2772 Python faithfully relays to you the information returned by the OS in these cases. I don't think it's planned for Python to try to rationalize the various errno/GetLastError() values based on what it thinks the actual error must have been. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738617&group_id=5470 From noreply@sourceforge.net Mon May 19 05:21:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 21:21:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-738617 ] On Windows, os.listdir() throws incorrect exception Message-ID: <E19Hc9p-0000Yp-00@sc8-sf-web2.sourceforge.net> Bugs item #738617, was opened at 2003-05-15 23:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738617&group_id=5470 >Category: Windows >Group: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Mike Thompson (mikethompson) >Assigned to: Tim Peters (tim_one) Summary: On Windows, os.listdir() throws incorrect exception Initial Comment: 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 os >>> os.listdir('c:\IMPOSSIBLE') Traceback (most recent call last): File "<stdin>", line 2, in ? WindowsError: [Errno 3] The system cannot find the path specified: 'c:\IMPOSSIBLE/*.*' This is the wrong exception I would have thought. AIUI, WindowsError is thrown for uniquely Windows types of problems. Path not found is not unique to Windows. I would have expected an os.error exception to have been thrown together with an code of errno.ENOENT. This is what happens if I try to open() a non existent file. (Caution: I'm a python newbie and I could easily have missed something here -- If so sorry to waste your time) The deadly part about this bug is that WindowsError subclasses os.error, just the code changes (3 instead of 2). So my "except os.error" worked to catch the exception ... just the error code seemed wrong. Took be ages to figure it all out. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-19 00:21 Message: Logged In: YES user_id=31435 WindowsError gets raised when the implementation uses a native Win32 API function instead of a standard C library function: no native Win32 API function sets errno, and the error code we get is gotten from the Win32 GetLastError() function instead.. os.listdir() on Windows uses the Win32 FindFirstFile()/FindNextFile() API. That doesn't set errno. When a path can't be found by FindFisrtFile(), GetLastError () returns 3, which is the Windows ERROR_PATH_NOT_FOUND. That's what we tell you. On Unix systems, the POSIX opendir()/readdir()/closedir() API is used. That does set errno, and we return whatever errno it sets there. On OS2, we use its DosFindFirst()/DosFindNext() API. Etc. The reason this isn't uniform is that standard C doesn't define a way to list a directory, so how to get it done necessarily varies across platforms. In platform- specific code, we generally strive to give platform-natural error codes. open() is different because standard C defines what open() does, so it can be done the same way across platfroms. There isn't "a bug" here, so I'm closing this. If you want to open a feature request asking that error codes be made uniform across all platforms, you can do so, but I'll tell you it's unlikely to happen -- there are cases where no cross- platform standard exists, and, e.g., to a Win32 programmer it wouldn't make sense for listdir() to return a POSIX errno code. It's not impossble for Python to make it do so anyway, but Python chose a different way at the start and changing now would break backward compatibility. A change here would therefore require a PEP too. ---------------------------------------------------------------------- Comment By: Mike Thompson (mikethompson) Date: 2003-05-18 21:53 Message: Logged In: YES user_id=630223 Yet, if I try to open() a non existent file, this mapping to a generic Python exception DOES occur (exception is os.error, code is errno.ENOENT) And just as well it does too because otherwise cross-platform coding would be difficult. Now, if its good enough for open(), why not for os.listdir()? >From the documentation, I got the impression that WindowError gets used for Windows specific problems for which generic cross-platform handling makes no sense, which is why WindowsError simply wraps errno/GetLastError () and sub-classes the standard exception. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-05-18 21:33 Message: Logged In: YES user_id=2772 Python faithfully relays to you the information returned by the OS in these cases. I don't think it's planned for Python to try to rationalize the various errno/GetLastError() values based on what it thinks the actual error must have been. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738617&group_id=5470 From noreply@sourceforge.net Mon May 19 06:28:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 22:28:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: <E19HdCP-0007EJ-00@sc8-sf-web4.sourceforge.net> Bugs item #729317, was opened at 2003-04-29 05:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a <type 'float'> and _tkinter.TCL_VERSION is a <type 'str'> Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-19 07:28 Message: Logged In: YES user_id=21627 I disagree that patch #518625 is in error; _tkinter uses only official Tcl API to access Tcl objects. It is certainly the case that a computation with tcl_version may cause it to change its type from string. However, I would still like to find out where exactly that happens on the Mac, as it happens nowhere else, and Tkinter most certainly does not use any Tcl code that may trigger such a change. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-18 23:22 Message: Logged In: YES user_id=45365 Martin, I'm assigning back to you, because I'm out of my water here. I discussed this problem with the MacTcl people, and it seems that what was checked in in _tkinter.c for patch 518625 is not correct: if something is initialized as a string in Tcl and then some code accesses it as a float the internal float representation will be created automatically. In other words: the FromObj() code attempts to graft Python semantics on Tcl objects, which is prone to obscure errors. Here are some excerpts from relevant mail messages: ------------- >From Jim Ingham: tcl_version is created as a string variable with the value "8.2". If somebody tried to do some math with it (like evaluate expr $tcl_version <= 8.4 or something) then Tcl would set the internal representation to a float. I don't see any place where we are doing that, but maybe your Tkinter code does that to check something on Mac OS X? Anyway that would not be an error on Tcl's part. If you want tcl_version in Python explicitly as a string, you need to make sure the string representation exists, and then get the variable as a string. You can't rely on their being or not being any particular internal representation. ------------------ And from Benjamin Riefenstahl: Well, somebody may already have told you that, but that's not how Tcl works. In Tcl *all* values are strings. You use Tcl_GetStringFromObj() to get that value. That's it. If you want a floating point, you explicitly *convert* by using Tcl_GetDoubleFromObj(). Everything you see related to "types" is just internal speed optimizations to avoid double conversions. These internal representations come and go at the whim of the implementation. Accessing these infos without the official APIs will lead to errors and inconsistent behaviour, as you have seen. The details of the behaviour will also quite likely change from Tcl version to Tcl version. --------------- ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:29 Message: Logged In: YES user_id=21627 This seems to happen only in the Mac version of Tcl. I can't reproduce it on Linux or Windows, and I can't see anything in the Tcl sources that may causing it. tcl_version is set in generic/tclBasic.c using Tcl_SetVar, i.e. as a string. It is never referred-to in the Tcl sources, except for being returned from 'info tclversion'. So I can't see why it would ever be changed to a floating point object. Perhaps the Mac is not using the original Tcl source code? Assigning to Jack for further investigation. ---------------------------------------------------------------------- Comment By: Larry Bugbee (thunderbug) Date: 2003-05-10 04:44 Message: Logged In: YES user_id=10953 Several of us have encountered this. Personally, I have seen this with Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2. ...and with Tcl/Tk 8.4.2. ...and under 10.2.5 and 2.3b1. I've tried several combinations. My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/ python/mac/ . I hope this helps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 00:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 07:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Mon May 19 14:25:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 06:25:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: <E19HkeI-0001fp-00@sc8-sf-web1.sourceforge.net> Bugs item #729317, was opened at 2003-04-29 05:41 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a <type 'float'> and _tkinter.TCL_VERSION is a <type 'str'> Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-19 15:25 Message: Logged In: YES user_id=45365 I did some more investigating, and it turns out that Jim and Benjamin's analysis of the problem is correct. The distribution that most people install for MacOSX is a "batteries included" distribution of Tcl/Tk, which includes lots of optional packages that initialize themselves. Some of these initializations do a compare of tcl_version to the numeric value 8.3 or so, thereby coercing tcl_version to a float. I removed all traces of tcl/tk from my machine and installed a minimal tcl/tk and the problem does not occur. On Linux everyone apparently installs a bare tcl/tk, but once you install incrTcl or whatever yourself you will run into the same problem. As to your (Martin's) statement that _tkinter uses only official Tcl APIs: the TCL folks disagree with this. The official way to get a float from a tcl object is using Tcl_GetDoubleFromObj(), not looking at the cached internal value. A tcl object is a string, and that's all there is. Anything else is optimization. The question now is really: how important is patch #518625. It apparently breaks Tcl object semantics, is the added convenience worth it. If it is then we simply add str() calls around the comparison of tcl_version in Tkinter, but then we should remember that this same problem will show up in different guises later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-19 07:28 Message: Logged In: YES user_id=21627 I disagree that patch #518625 is in error; _tkinter uses only official Tcl API to access Tcl objects. It is certainly the case that a computation with tcl_version may cause it to change its type from string. However, I would still like to find out where exactly that happens on the Mac, as it happens nowhere else, and Tkinter most certainly does not use any Tcl code that may trigger such a change. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-18 23:22 Message: Logged In: YES user_id=45365 Martin, I'm assigning back to you, because I'm out of my water here. I discussed this problem with the MacTcl people, and it seems that what was checked in in _tkinter.c for patch 518625 is not correct: if something is initialized as a string in Tcl and then some code accesses it as a float the internal float representation will be created automatically. In other words: the FromObj() code attempts to graft Python semantics on Tcl objects, which is prone to obscure errors. Here are some excerpts from relevant mail messages: ------------- >From Jim Ingham: tcl_version is created as a string variable with the value "8.2". If somebody tried to do some math with it (like evaluate expr $tcl_version <= 8.4 or something) then Tcl would set the internal representation to a float. I don't see any place where we are doing that, but maybe your Tkinter code does that to check something on Mac OS X? Anyway that would not be an error on Tcl's part. If you want tcl_version in Python explicitly as a string, you need to make sure the string representation exists, and then get the variable as a string. You can't rely on their being or not being any particular internal representation. ------------------ And from Benjamin Riefenstahl: Well, somebody may already have told you that, but that's not how Tcl works. In Tcl *all* values are strings. You use Tcl_GetStringFromObj() to get that value. That's it. If you want a floating point, you explicitly *convert* by using Tcl_GetDoubleFromObj(). Everything you see related to "types" is just internal speed optimizations to avoid double conversions. These internal representations come and go at the whim of the implementation. Accessing these infos without the official APIs will lead to errors and inconsistent behaviour, as you have seen. The details of the behaviour will also quite likely change from Tcl version to Tcl version. --------------- ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:29 Message: Logged In: YES user_id=21627 This seems to happen only in the Mac version of Tcl. I can't reproduce it on Linux or Windows, and I can't see anything in the Tcl sources that may causing it. tcl_version is set in generic/tclBasic.c using Tcl_SetVar, i.e. as a string. It is never referred-to in the Tcl sources, except for being returned from 'info tclversion'. So I can't see why it would ever be changed to a floating point object. Perhaps the Mac is not using the original Tcl source code? Assigning to Jack for further investigation. ---------------------------------------------------------------------- Comment By: Larry Bugbee (thunderbug) Date: 2003-05-10 04:44 Message: Logged In: YES user_id=10953 Several of us have encountered this. Personally, I have seen this with Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2. ...and with Tcl/Tk 8.4.2. ...and under 10.2.5 and 2.3b1. I've tried several combinations. My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/ python/mac/ . I hope this helps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 00:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 07:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Mon May 19 16:46:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 08:46:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-739909 ] IMAP4_SSL broken Message-ID: <E19Hmq5-0005Ip-00@sc8-sf-web1.sourceforge.net> Bugs item #739909, was opened at 2003-05-19 17: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=739909&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: IMAP4_SSL broken Initial Comment: Python 2.3b1 (#1, May 6 2003, 10:52:33) [GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import imaplib >>> imaplib.IMAP4_SSL('mailserver') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.3/imaplib.py", line 1071, in __init__ IMAP4.__init__(self, host, port) File "/usr/lib/python2.3/imaplib.py", line 156, in __init__ self.open(host, port) File "/usr/lib/python2.3/imaplib.py", line 1084, in open self.sslobj = socket.ssl(self.sock, self.keyfile, self.certfile) TypeError: ssl() argument 1 must be _socket.socket, not _socketobject ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739909&group_id=5470 From noreply@sourceforge.net Mon May 19 16:52:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 08:52:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-738066 ] Interpreter crash: sigfpe on Alpha Message-ID: <E19Hmw1-0005dt-00@sc8-sf-web1.sourceforge.net> Bugs item #738066, was opened at 2003-05-15 07:52 Message generated for change (Comment added) made by jensj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Jørgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter crash: sigfpe on Alpha Initial Comment: Multiplying two numbers makes the interpreter crash. The architecture is an Alpha running: Digital UNIX V4.0F (Rev. 1229); Sat Oct 26 16:44:55 MET DST 2002 Compaq Tru64 UNIX V4.0F (Rev. 1229); Thu Mar 23 08:45:31 MET 2000 Python 2.2.1 (#1, Jun 4 2002, 15:33:18) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.uname() ('OSF1', 'asrv', 'V4.0', '1229', 'alpha') >>> 1e300 * 1e300 Floating exception (core dumped) ---------------------------------------------------------------------- >Comment By: Jens Jørgen Mortensen (jensj) Date: 2003-05-19 17:52 Message: Logged In: YES user_id=716463 I tried with Python-2.3b1: Same problem. I then tried building with -ieee added to CFLAGS in Makefile - That solved the problem! Thanks ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-15 20:31 Message: Logged In: YES user_id=31435 Python inherits its floating-point behavior from whatever your C compiler and libraries happen to do. So, presumably a plain C program would do the same thing with this example. If that's not what you want, your C compiler probably supports some option to compile code that acts more the way you want it to work, and then you should compile Python with that option too. IIRC (I've never run on an Alpha), by default Alphas don't have compliant IEEE-754 fp arithmetic, and by default C compilers on Alphas don't try to repair that. If the compiler you're using as an option named "-ieee", try it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-15 16:11 Message: Logged In: YES user_id=33168 Is this still a problem with 2.2.2 or 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 From noreply@sourceforge.net Mon May 19 17:00:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 09:00:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-735293 ] Command line timeit.py sets sys.path badly Message-ID: <E19Hn3l-0002Jm-00@sc8-sf-web2.sourceforge.net> Bugs item #735293, was opened at 2003-05-09 16:36 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Guido van Rossum (gvanrossum) Summary: Command line timeit.py sets sys.path badly Initial Comment: Running timeit.py from the command line results in the directory containing timeit.py (ie, the standard Python library) being added to sys.path, and the current directory *not* being. To test, create a file mymod.py in the current directory, containing def test(): "Stupid test function" L = [] for i in range(100): L.append(i) Now, execute \Apps\Python\Lib\timeit.py -s "import mymod" "mymod.test()" Result is Traceback (most recent call last): File "\Apps\Python\Lib\timeit.py", line 245, in main x = t.timeit(number) File "\Apps\Python\Lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "<timeit-src>", line 3, in inner import mymod ImportError: No module named mymod It's possible to work around this, either by setting PYTHONPATH in the environment to ".", or by adding "import sys; sys.path.insert(0, '.')" to the code in the -s option. But neither is a particularly attractive solution. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2003-05-19 17:00 Message: Logged In: YES user_id=113328 This patch does what I'd expect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-16 20:03 Message: Logged In: YES user_id=6380 Good point. Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 From noreply@sourceforge.net Mon May 19 18:42:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 10:42:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-738066 ] Interpreter crash: sigfpe on Alpha Message-ID: <E19HoeP-0000Hb-00@sc8-sf-web4.sourceforge.net> Bugs item #738066, was opened at 2003-05-15 01:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Jørgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter crash: sigfpe on Alpha Initial Comment: Multiplying two numbers makes the interpreter crash. The architecture is an Alpha running: Digital UNIX V4.0F (Rev. 1229); Sat Oct 26 16:44:55 MET DST 2002 Compaq Tru64 UNIX V4.0F (Rev. 1229); Thu Mar 23 08:45:31 MET 2000 Python 2.2.1 (#1, Jun 4 2002, 15:33:18) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.uname() ('OSF1', 'asrv', 'V4.0', '1229', 'alpha') >>> 1e300 * 1e300 Floating exception (core dumped) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-19 13:42 Message: Logged In: YES user_id=31435 If someone knows how to make a config patch to pass -ieee automatically to this compiler, that would be helpful -- IIRC, this comes up a couple times per year. ---------------------------------------------------------------------- Comment By: Jens Jørgen Mortensen (jensj) Date: 2003-05-19 11:52 Message: Logged In: YES user_id=716463 I tried with Python-2.3b1: Same problem. I then tried building with -ieee added to CFLAGS in Makefile - That solved the problem! Thanks ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-15 14:31 Message: Logged In: YES user_id=31435 Python inherits its floating-point behavior from whatever your C compiler and libraries happen to do. So, presumably a plain C program would do the same thing with this example. If that's not what you want, your C compiler probably supports some option to compile code that acts more the way you want it to work, and then you should compile Python with that option too. IIRC (I've never run on an Alpha), by default Alphas don't have compliant IEEE-754 fp arithmetic, and by default C compilers on Alphas don't try to repair that. If the compiler you're using as an option named "-ieee", try it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-15 10:11 Message: Logged In: YES user_id=33168 Is this still a problem with 2.2.2 or 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 From noreply@sourceforge.net Mon May 19 19:52:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 11:52:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-740026 ] re.finditer() listed as new in 2.2.? Message-ID: <E19HpkX-0001G5-00@sc8-sf-web3.sourceforge.net> Bugs item #740026, was opened at 2003-05-19 20:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: re.finditer() listed as new in 2.2.? Initial Comment: Documentation says re.finditer() is new in 2.2 (http://www.python.org/doc/current/lib/node99.html), but this is not totally correct: [gradha@ws5:0] [~/cms_freeze]$ python Python 2.2.1 (#1, Sep 10 2002, 17:49:17) [GCC 3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.finditer Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'finditer' [0:arpa/g/gradha> /usr/pkg/bin/python2.2 Python 2.2.2 (#1, Mar 13 2003, 22:53:11) [GCC 2.95.3 20010315 (release) (NetBSD nb3)] on netbsd1 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.finditer <function finditer at 0x1201ed218> The first log was produced on an 8.1 Suse default distro. For a moment I wanted to blame Suse, but I thought: "hey, let's blame the documentation!". Please extend that version number to 2.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470 From noreply@sourceforge.net Mon May 19 20:48:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 12:48:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: <E19HqcX-0007Ak-00@sc8-sf-web4.sourceforge.net> Bugs item #729317, was opened at 2003-04-29 05:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a <type 'float'> and _tkinter.TCL_VERSION is a <type 'str'> Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-19 21:48 Message: Logged In: YES user_id=21627 On incrTcl: I still cannot reproduce that. On Linux, incrTcl is typically installed, but it comes as a Tcl package. So it won't get loaded until somebody does 'package require Itcl'. On loading that package, I see no change in type of tcl_version. Grepping the source of Itcl 3.2.1, I find no occurrence of tcl_version. What specific file contains what specific access to tcl_version on your system? On using internal APIs: I see, using GetDoubleFromObj is probably better. However, it won't change the behaviour at all: Python accesses the double representation only if it already knows the Tcl object is a double. In that case, Tcl_GetDoubleFromObj does exactly the same thing that _tkinter already does. On the importance of #518625: It is important for the following reasons: a) it allows to round-trip doubles without loss of precision. That fixes #721171. b) it improves type safety, by returning the proper object types for widget attributes. c) it improves efficiency, but not requiring expensive string-object conversions. It also provides full backwards compatibility, by allowing applications to set Tkinter.wantobjects=False. I'll try to come up with a fix for this bug, although I would really prefer if I could reproduce it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-19 15:25 Message: Logged In: YES user_id=45365 I did some more investigating, and it turns out that Jim and Benjamin's analysis of the problem is correct. The distribution that most people install for MacOSX is a "batteries included" distribution of Tcl/Tk, which includes lots of optional packages that initialize themselves. Some of these initializations do a compare of tcl_version to the numeric value 8.3 or so, thereby coercing tcl_version to a float. I removed all traces of tcl/tk from my machine and installed a minimal tcl/tk and the problem does not occur. On Linux everyone apparently installs a bare tcl/tk, but once you install incrTcl or whatever yourself you will run into the same problem. As to your (Martin's) statement that _tkinter uses only official Tcl APIs: the TCL folks disagree with this. The official way to get a float from a tcl object is using Tcl_GetDoubleFromObj(), not looking at the cached internal value. A tcl object is a string, and that's all there is. Anything else is optimization. The question now is really: how important is patch #518625. It apparently breaks Tcl object semantics, is the added convenience worth it. If it is then we simply add str() calls around the comparison of tcl_version in Tkinter, but then we should remember that this same problem will show up in different guises later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-19 07:28 Message: Logged In: YES user_id=21627 I disagree that patch #518625 is in error; _tkinter uses only official Tcl API to access Tcl objects. It is certainly the case that a computation with tcl_version may cause it to change its type from string. However, I would still like to find out where exactly that happens on the Mac, as it happens nowhere else, and Tkinter most certainly does not use any Tcl code that may trigger such a change. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-18 23:22 Message: Logged In: YES user_id=45365 Martin, I'm assigning back to you, because I'm out of my water here. I discussed this problem with the MacTcl people, and it seems that what was checked in in _tkinter.c for patch 518625 is not correct: if something is initialized as a string in Tcl and then some code accesses it as a float the internal float representation will be created automatically. In other words: the FromObj() code attempts to graft Python semantics on Tcl objects, which is prone to obscure errors. Here are some excerpts from relevant mail messages: ------------- >From Jim Ingham: tcl_version is created as a string variable with the value "8.2". If somebody tried to do some math with it (like evaluate expr $tcl_version <= 8.4 or something) then Tcl would set the internal representation to a float. I don't see any place where we are doing that, but maybe your Tkinter code does that to check something on Mac OS X? Anyway that would not be an error on Tcl's part. If you want tcl_version in Python explicitly as a string, you need to make sure the string representation exists, and then get the variable as a string. You can't rely on their being or not being any particular internal representation. ------------------ And from Benjamin Riefenstahl: Well, somebody may already have told you that, but that's not how Tcl works. In Tcl *all* values are strings. You use Tcl_GetStringFromObj() to get that value. That's it. If you want a floating point, you explicitly *convert* by using Tcl_GetDoubleFromObj(). Everything you see related to "types" is just internal speed optimizations to avoid double conversions. These internal representations come and go at the whim of the implementation. Accessing these infos without the official APIs will lead to errors and inconsistent behaviour, as you have seen. The details of the behaviour will also quite likely change from Tcl version to Tcl version. --------------- ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:29 Message: Logged In: YES user_id=21627 This seems to happen only in the Mac version of Tcl. I can't reproduce it on Linux or Windows, and I can't see anything in the Tcl sources that may causing it. tcl_version is set in generic/tclBasic.c using Tcl_SetVar, i.e. as a string. It is never referred-to in the Tcl sources, except for being returned from 'info tclversion'. So I can't see why it would ever be changed to a floating point object. Perhaps the Mac is not using the original Tcl source code? Assigning to Jack for further investigation. ---------------------------------------------------------------------- Comment By: Larry Bugbee (thunderbug) Date: 2003-05-10 04:44 Message: Logged In: YES user_id=10953 Several of us have encountered this. Personally, I have seen this with Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2. ...and with Tcl/Tk 8.4.2. ...and under 10.2.5 and 2.3b1. I've tried several combinations. My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/ python/mac/ . I hope this helps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 00:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 07:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Mon May 19 20:53:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 12:53:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-692776 ] new.function() leads to segfault Message-ID: <E19Hqhf-0004zk-00@sc8-sf-web2.sourceforge.net> Bugs item #692776, was opened at 2003-02-25 08:04 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692776&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Jp Calderone (kuran) Assigned to: Jeremy Hylton (jhylton) Summary: new.function() leads to segfault Initial Comment: If a code object which requires a closure is passed to new.function(), a segfault (Python/ceval.c:2578). This seems to be fixed in 2.3. Attached is a short code example that demonstrates the behavior. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-04-09 18:57 Message: Logged In: YES user_id=31392 I think I can swap in the state without too much pain. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-09 10:48 Message: Logged In: YES user_id=6656 Jeremy, is this easy for you to fix? It's fiddlier than I expected. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-02-25 09:31 Message: Logged In: YES user_id=6656 You're right. I guess the fix is to backport the extra 'closure' argument from 2.3. I'll look into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692776&group_id=5470 From noreply@sourceforge.net Mon May 19 20:54:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 12:54:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-740055 ] optional argument protocol in shelve.open is ignored Message-ID: <E19HqiC-0007Wv-00@sc8-sf-web4.sourceforge.net> Bugs item #740055, was opened at 2003-05-19 21:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740055&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fedor Baart (siggyf) Assigned to: Nobody/Anonymous (nobody) Summary: optional argument protocol in shelve.open is ignored Initial Comment: In the shelve module in method open() the argument protocol is not passed to the DbfilenameShelf instance. This is easily solved by changing the last line of shelve.py from: return DbfilenameShelf(filename, flag, binary, writeback) into return DbfilenameShelf(filename, flag, protocol, binary, writeback) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740055&group_id=5470 From noreply@sourceforge.net Mon May 19 21:01:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 13:01:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-667931 ] BoundaryError: multipart message with no defined boundary Message-ID: <E19HqpS-0007xf-00@sc8-sf-web4.sourceforge.net> Bugs item #667931, was opened at 2003-01-14 13:36 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: BoundaryError: multipart message with no defined boundary Initial Comment: More problems with the email package raising exceptions when trying to parse non-compliant messages. Even when lax parsing is enabled, a BoundaryError is raised when trying to parse the attached spam message. I'd like to see some sort of workaround to handle these cases more gracefully when when lax parsing is enabled. This behavior seems like 'strict' parsing behavior to me. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 16:01 Message: Logged In: YES user_id=12800 Closing as per jasonrm's last update. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-04-27 00:53 Message: Logged In: YES user_id=85984 Ok, I see now. I ended up replacing use of email.message_from_file() with my own implementation based upon email.Parser.HeaderParser. HeaderParser completely slipped past me. I might suggest noting it a bit more prominently in the docs, perhaps in 2.2.1 under the description of the Parser class. Even if there's some redundancy, it will help bring HeaderParser to the attention of more programmers. You can close this one out, thanks. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-26 21:49 Message: Logged In: YES user_id=12800 HeaderParser is a parser that stops after reading just the rfc 2822 headers, leaving the entirety of the body of the message as one big text payload. Sometimes that's the best you can do. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-04-26 15:17 Message: Logged In: YES user_id=85984 I'm unclear what you mean by: ``You can always fall back to email.Header.HeaderParser when all else fails'' ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:31 Message: Logged In: YES user_id=12800 I see what you're saying, Jason, but I don't know how Parser could do much better. You can always fall back to email.Header.HeaderParser when all else fails (well all else modulo severely broken headers). ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-02-20 14:33 Message: Logged In: YES user_id=85984 As Python 2.3a2 was just released, I'm worried that this one is going to fall through the cracks before 2.3-final is released which would be unfortunate because it would mean I'd have to continue bundling my own copy of email with my applications. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 From noreply@sourceforge.net Mon May 19 21:00:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 13:00:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-724621 ] email/quopriMIME.py exception on int (lstrip) Message-ID: <E19HqoY-0007sf-00@sc8-sf-web4.sourceforge.net> Bugs item #724621, was opened at 2003-04-20 11:36 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Pending Resolution: None Priority: 5 Submitted By: Moshe Yudkowsky (myudkowsky) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/quopriMIME.py exception on int (lstrip) Initial Comment: Python 2.3a2+, Debian Summary: when I use the as_string() method on a multipart, multilevel message, I get an exception from email/quopriMIME.py, line 84, complaining about lstrip() of an integer. Initial condtions: I have a script that reads an email message, extracts some information, encapsulates the message and then forwards it with some commentary. This script works under Python 2.2.2. Failure: This script does not run under 2.3a2+ -- it fails on the as_string() method. In particular, at the file/lineno given above. Using the debugger, I see that in fact there *is* an integer at that point, the digit "1" to be exact. Looking up in the stack, I see that this function was called by the method _encode_chunks in Headers.py, and that the "newchunks" was [ (1, us-ascii ) ]. Please let me know if you need copies of the scripts, email messages, etc. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 16:00 Message: Logged In: YES user_id=12800 Moving to Pending, waiting on more information. In 14 days, if there's no follow up this bug report will be automatically closed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-15 10:08 Message: Logged In: YES user_id=12800 Yes, please upload (not paste) all relevant files needed for me to reproduce the problem. Please boil down your example as much as possible, but be sure to include a complete example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 From noreply@sourceforge.net Mon May 19 21:04:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 13:04:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module Message-ID: <E19HqsF-0002dL-00@sc8-sf-web1.sourceforge.net> Bugs item #408271, was opened at 2001-03-13 13:14 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry A. Warsaw (bwarsaw) Summary: crash in shelve module Initial Comment: While using shelve module on SGI sloth 271> uname -a IRIX64 sloth 6.5 04191225 IP27 my python program crashes and I am getting following error message: File "/usr/local/lib/python1.5/shelve.py", line 71, in __setitem__ self.dict[key] = f.getvalue() bsddb.error: (0, 'Error') At the time the size of the "shelve" file was quite big (maybe this is a problem ?) sloth 267> ls -lt *shelve -rw-r--r-- 1 ryszard cdiApps 85778432 Mar 13 12:27 recap_mddr.shelve ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 16:04 Message: Logged In: YES user_id=12800 I think the fact that pybsddb is now the default bsddb module makes this bug report out of date. Closing. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-16 00:32 Message: Logged In: YES user_id=12800 I'll re-open this one as a reminder to myself to deal with this somehow. All I know is that distutils build of bsddbmodule fails for all the Linux flavors I've tested it on. I think the autodetection of the library to link against is busted in Py2.2 & 2.3. I don't have time to think more about this now, but I will make sure I do /something/ about it for Py2.3. ---------------------------------------------------------------------- Comment By: Martin D Katz, Ph.D. (drbits) Date: 2002-05-15 21:09 Message: Logged In: YES user_id=276840 Apparently, this problem only occurs when the hash table form of bsddb is used. The b-bree version (btopen) does not have this problem. ---------------------------------------------------------------------- Comment By: Martin D Katz, Ph.D. (drbits) Date: 2002-05-15 21:02 Message: Logged In: YES user_id=276840 Apparently, this problem only occurs when the hash table form of bsddb is used. The b-bree version (btopen) does not have this problem. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-06 23:56 Message: Logged In: YES user_id=29957 Barry, if it's known to be stuffed, why is it still there? Is there an open bug report for how it's busted? A bunch of stuff that depends on getting "a db storage" is going to use bsddb... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2002-05-06 23:49 Message: Logged In: YES user_id=59803 Submitted patch #553108. ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2002-05-06 22:35 Message: Logged In: YES user_id=59803 If bssdb is broken, shelve should use anydbm and bsddb should be deprecated. Precedence: regexp. ActivePython 2.2.0 Build 221 (ActiveState Corp.) based on Python 2.2 (#28, Mar 28 2002, 12:10:20) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import shelve >>> s = shelve.open('temp.db', 'c') >>> s.dict <bsddb.bsddb object at 0x008A2D48> Python 2.2.1 (#1, Apr 30 2002, 17:02:05) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import shelve >>> s = shelve.open('temp.db', 'c') >>> s.dict <bsddb.bsddb object at 0x815a388> >>> ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-06 11:13 Message: Logged In: YES user_id=12800 I'd highly suggest that any serious work with BerkeleyDB be done with pybsddb and a more modern version of Berkeley. The bsddb module that comes with Python 2.2 has serious problems, including not being able to link on some *nix distros. Also BDB 1.85 is way way old and has many known problems. I ran the deadlybloddyserious example using BDB 3.11 and pybsddb 3.0 and it passed with flying colors. See www.sleepycat.com for the latest BDB's and pybsddb.sf.net for the latest Python wrappers. ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2002-05-06 03:55 Message: Logged In: YES user_id=59803 You might want to re-open this one, Barry. The problem seems to be with any large number of bsddb inserts, which can also be triggered by shelve. See: http://www.deadlybloodyserious.com/Python/2002/05/06.html http://bugs.activestate.com/show_bug.cgi?id=10242 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-03-18 11:10 Message: Logged In: YES user_id=12800 Besides, this was submitted by "anonymous" and the only clue to the identity of the original poster is in the ls output. Unfortunately, I'm not prepared to spam all the Ryszard's in my name database. :) I'm closing this report until/unless we get more information. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-18 01:03 Message: Logged In: YES user_id=31435 Assigned to Barry because there's not enough info here to do anything about it <wink>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470 From noreply@sourceforge.net Mon May 19 20:59:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 12:59:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-736407 ] Problem With email.MIMEText Package Message-ID: <E19HqnT-0004qf-00@sc8-sf-web3.sourceforge.net> 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-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@sourceforge.net Mon May 19 21:11:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 13:11:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-732951 ] bsddb.*open mode should default to 'r' rather than 'c' Message-ID: <E19Hqz0-00064Q-00@sc8-sf-web2.sourceforge.net> Bugs item #732951, was opened at 2003-05-05 18:35 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732951&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) >Assigned to: Gregory P. Smith (greg) Summary: bsddb.*open mode should default to 'r' rather than 'c' Initial Comment: In module bsddb, the second argument of the open functions (e.g., btopen) should default to 'r' rather than 'c'. Most (all?) of the other open functions, both in the various dbm-like modules and for basic I/O default this way. If this change is not made, then at least this behavior should be documented clearly. Currently it's not documented at all (as far as I can find). Cheers, Mike ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 16:11 Message: Logged In: YES user_id=12800 That certainly would make it more consistent with other *dbm open functions. I guess you'd want to change hashopen(), btopen(), and rnopen(). OTOH, this probably breaks backward compatibility for those coming from the pybsddb world. Assigning to Greg Smith to make final decision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732951&group_id=5470 From noreply@sourceforge.net Mon May 19 21:12:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 13:12:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-676233 ] bsddb doc error Message-ID: <E19Hr0D-000088-00@sc8-sf-web4.sourceforge.net> Bugs item #676233, was opened at 2003-01-28 13:15 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676233&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bsddb doc error Initial Comment: Email from Magnus Lie Hetland to python-docs: While browsing the docs on the bsddb module and reading the source, I found that the signature of the rnopen (and probably the other open functions) is (are) incorrect in the docs. I don't really have a doc patch (sorry about that), but I suppose the error should be easy to fix...? Also, the description that the arguments are passed to the low-level dbopen function is not correct -- they are passed to several different methods. (I noticed this, as I looked for the set_re_source method, which is handled by the source argument, as it turns out.) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 16:12 Message: Logged In: YES user_id=12800 Closing since the whole of bsddb documentation needs updating. See SF bug #730938. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676233&group_id=5470 From noreply@sourceforge.net Mon May 19 22:01:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 14:01:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-735293 ] Command line timeit.py sets sys.path badly Message-ID: <E19HrlJ-00084i-00@sc8-sf-web3.sourceforge.net> Bugs item #735293, was opened at 2003-05-09 11:36 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Guido van Rossum (gvanrossum) Summary: Command line timeit.py sets sys.path badly Initial Comment: Running timeit.py from the command line results in the directory containing timeit.py (ie, the standard Python library) being added to sys.path, and the current directory *not* being. To test, create a file mymod.py in the current directory, containing def test(): "Stupid test function" L = [] for i in range(100): L.append(i) Now, execute \Apps\Python\Lib\timeit.py -s "import mymod" "mymod.test()" Result is Traceback (most recent call last): File "\Apps\Python\Lib\timeit.py", line 245, in main x = t.timeit(number) File "\Apps\Python\Lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "<timeit-src>", line 3, in inner import mymod ImportError: No module named mymod It's possible to work around this, either by setting PYTHONPATH in the environment to ".", or by adding "import sys; sys.path.insert(0, '.')" to the code in the -s option. But neither is a particularly attractive solution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-19 17:01 Message: Logged In: YES user_id=6380 I won't be offended if someone else checks this in and closes this issue. :) ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2003-05-19 12:00 Message: Logged In: YES user_id=113328 This patch does what I'd expect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-16 15:03 Message: Logged In: YES user_id=6380 Good point. Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 From noreply@sourceforge.net Tue May 20 00:52:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 16:52:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-735293 ] Command line timeit.py sets sys.path badly Message-ID: <E19HuR3-0006E8-00@sc8-sf-web2.sourceforge.net> Bugs item #735293, was opened at 2003-05-09 10:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Paul Moore (pmoore) >Assigned to: Raymond Hettinger (rhettinger) Summary: Command line timeit.py sets sys.path badly Initial Comment: Running timeit.py from the command line results in the directory containing timeit.py (ie, the standard Python library) being added to sys.path, and the current directory *not* being. To test, create a file mymod.py in the current directory, containing def test(): "Stupid test function" L = [] for i in range(100): L.append(i) Now, execute \Apps\Python\Lib\timeit.py -s "import mymod" "mymod.test()" Result is Traceback (most recent call last): File "\Apps\Python\Lib\timeit.py", line 245, in main x = t.timeit(number) File "\Apps\Python\Lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "<timeit-src>", line 3, in inner import mymod ImportError: No module named mymod It's possible to work around this, either by setting PYTHONPATH in the environment to ".", or by adding "import sys; sys.path.insert(0, '.')" to the code in the -s option. But neither is a particularly attractive solution. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-19 18:52 Message: Logged In: YES user_id=80475 I've got it from here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-19 16:01 Message: Logged In: YES user_id=6380 I won't be offended if someone else checks this in and closes this issue. :) ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2003-05-19 11:00 Message: Logged In: YES user_id=113328 This patch does what I'd expect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-16 14:03 Message: Logged In: YES user_id=6380 Good point. Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 From noreply@sourceforge.net Tue May 20 02:00:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 18:00:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-739424 ] Python2.3b1 install problems on Linux Message-ID: <E19HvUt-0008IN-00@sc8-sf-web2.sourceforge.net> Bugs item #739424, was opened at 2003-05-18 05:10 Message generated for change (Comment added) made by macquigg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 install problems on Linux Initial Comment: I'm running Red Hat Linux 8.0, patches fully up to date, with the latest tcl/tk packages installed. Python2.2.1 is running fine, including Tkinter and IDLE. Followed the standard install procedure for Python-2.3.b1 tarball, and Tkinter is now broken. Can't install IDLE. ./configure and make ran OK. ~/Python-2.3b1> make test 227 tests OK 26 skipped 1 unexpected skip on linux2: test_bz2 No module named bz2 ~/Python-2.3b1> make install ... building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -I/usr/X11R6/include -I. -I/home/macquigg/Python-2.3b1/./Include -I/usr/local/include -I/home/macquigg/Python-2.3b1/Include -I/home/macquigg/Python-2.3b1 -c /home/macquigg/Python-2.3b1/Modules/_tkinter.c -o build/temp.linux-i686-2.3/_tkinter.o cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" /usr/include/tk.h:597: parse error before "Bool" ... many more of these parse errors ... ==> Cannot find "Xlib.h" anywhere under /usr/include, /usr/X11R6, or in the Python-2.3b1 distribution. As far as I know, the X11 files have not been altered. Python 2.2.1 still runs OK. Here are the versions on the tcl/tk packages recently downloaded from RedHat. -rw-rw-r-- 1 macquigg macquigg 1570466 May 10 11:36 tcl-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 460160 May 10 13:47 tix-8.2.0b1-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 1390929 May 10 11:40 tk-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 265427 Apr 25 04:54 tkinter-2.2.1-17.i386.rpm More details in the attached logfile. I'll try to keep this configuration together for debugging. - Dave ---------------------------------------------------------------------- >Comment By: David MacQuigg (macquigg) Date: 2003-05-19 18:00 Message: Logged In: YES user_id=676422 Neal: According to Redhat Network, my package tkinter-2.2.1-17 is installed correctly, including resolution of all dependencies. I did find XFree86-devel-4.2.0-72, and I have scheduled that for installation. I'll let you know if that solves the problem. I'm suspecting a Red Hat problem. They don't do a very good job with checking these packages. Thanks for your help. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-18 13:57 Message: Logged In: YES user_id=33168 You will need the Xlib headers installed to build Tkinter. The RPM package which contains the headers is probably something like XFree86-devel-4-3.0-2. Try installing that package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 From noreply@sourceforge.net Tue May 20 02:37:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 18:37:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-740026 ] re.finditer() listed as new in 2.2.? Message-ID: <E19Hw4R-0000xa-00@sc8-sf-web2.sourceforge.net> Bugs item #740026, was opened at 2003-05-19 14:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: re.finditer() listed as new in 2.2.? Initial Comment: Documentation says re.finditer() is new in 2.2 (http://www.python.org/doc/current/lib/node99.html), but this is not totally correct: [gradha@ws5:0] [~/cms_freeze]$ python Python 2.2.1 (#1, Sep 10 2002, 17:49:17) [GCC 3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.finditer Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'finditer' [0:arpa/g/gradha> /usr/pkg/bin/python2.2 Python 2.2.2 (#1, Mar 13 2003, 22:53:11) [GCC 2.95.3 20010315 (release) (NetBSD nb3)] on netbsd1 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.finditer <function finditer at 0x1201ed218> The first log was produced on an 8.1 Suse default distro. For a moment I wanted to blame Suse, but I thought: "hey, let's blame the documentation!". Please extend that version number to 2.2.2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-19 21:37 Message: Logged In: YES user_id=33168 This is a bit of a weird case. From looking through CVS, finditer is in sre, but due to a bug it was not exported from re. So import sre ; sre.finditer should work, but from sre import * doesn't. I'm not sure how best to handle this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470 From noreply@sourceforge.net Tue May 20 03:43:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 19:43:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-560064 ] inconsistent behavior of __getslice__ Message-ID: <E19Hx68-0002mv-00@sc8-sf-web3.sourceforge.net> Bugs item #560064, was opened at 2002-05-24 04:59 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Cesar Douady (douady) Assigned to: Brett Cannon (bcannon) Summary: inconsistent behavior of __getslice__ Initial Comment: The following trace shows what I mean: >>> help(str.__getslice__) Help on wrapper_descriptor: __getslice__(...) x.__getslice__(i, j) <==> x[i:j] >>> 'ab'[-1] 'b' >>> 'ab'.__getitem__(-1) 'b' >>> 'ab'[-2:-1] 'a' >>> 'ab'.__getslice__(-2,-1) '' that is, __getslice__ does not add the length of the sequence to its arguments when they are negative as indexing with [:] does. This contradicts the docstring which says __getslice__ is equivalent to indexing. The same behavior applies to lists. Note that __getitem__ does it right. This bug may be linked to bug 473985 ('str, __getitem__ and slices') but should be much easier to fix. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-19 19:43 Message: Logged In: YES user_id=357491 Fixed as revision 2.232 on HEAD (after getting it right; bah) and as 2.126.4.35 on release22-maint. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 14:05 Message: Logged In: YES user_id=6380 Yes, please fix the docstring. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:19 Message: Logged In: YES user_id=357491 If the docstring fix is still the best way to fix this I am willing to make the change. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 12:23 Message: Logged In: YES user_id=6380 This should NOT be fixed this way, Raymond! The docs are (subtly) wrong. For historical reasons, __getslice__ expects the Python VM to do the adjustment of negative indices. If you did another adjustment inside getslice, certain indices would start behaving differently (e.g. s[:-5] where len(s)==3). Maybe the docstring should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 05:58 Message: Logged In: YES user_id=80475 Tim, I attached a tiny patch which fixes the behavior for strings. I've also tried out the same change in listobject.c and unicodeobject.c. Is this the right this to do or are there more subtleties to this than meet the eye? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470 From noreply@sourceforge.net Tue May 20 03:57:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 19:57:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-458447 ] New httplib lacks documentation Message-ID: <E19HxJS-0003Fc-00@sc8-sf-web2.sourceforge.net> Bugs item #458447, was opened at 2001-09-04 10:01 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=458447&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Rich Salz (rsalz) Assigned to: Brett Cannon (bcannon) Summary: New httplib lacks documentation Initial Comment: urllib should allow the user to set the content-type. This would allow applications to do more than just "forms posting" -- e.g., use it to make SOAP requests. The attached patch allows that. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-19 19:57 Message: Logged In: YES user_id=357491 OK, docs added and backported. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 23:36 Message: Logged In: YES user_id=357491 It looks like the parameters to HTTPSConnection have changed and are now ``def __init__(self, host, port=None, key_file=None, cert_file=None, strict=None):``. The docs on the key file and cert file can probably be copied from socket.ssl . ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-12-18 09:34 Message: Logged In: YES user_id=36737 The **x509 parameter of HTTPSConnection needs to be documented. It's a dictionary with at most two keys. key_file specifies the PEM-fformat private key file and cert_file specifies contains the PEM-format certificate and optional list of CA's in the cert chain. (I believe there's an open defect for SSL sockets not being docuemented.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-29 22:07 Message: Logged In: YES user_id=3066 Checked in as Doc/lib/libhttplib.tex revision 1.28. Updates contributed by Kalle Svensson. Thanks, Kalle! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-26 13:51 Message: Logged In: YES user_id=3066 I have contributed docs for the new version waiting for review in my inbox; these should be checked in this week. Bumping priority so this stays visible to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:37 Message: Logged In: YES user_id=6380 Fred: it turns out the httplib docs still document the old version of the module. The new version is considerably more powerful, and is essentially undocumented. Maybe you can shame Greg Stein into providing some docs, or maybe you can convert the copious docstrings to LaTeX. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-09-04 20:45 Message: Logged In: YES user_id=44345 I'm not sure why you'd want to program SOAP (or XMLRPC, for that matter) directly. You would (normally) only use those protocols through special-purpose modules like SOAP.py or xmlrpclib.py, both of which talk to httplib I believe. I don't see that allowing the Content-Type: header to be overridden at the urllib level is all that necessary. If you're going to want to mess with Content-Type: you're probably going to want to mess with other headers as well. ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-09-04 19:02 Message: Logged In: YES user_id=36737 I created this bug because urllib didn't let you set the content-type header. Guido pointed out that I should be using httplib. I didn't use httplib because I didn't know until I read the source, that httplib had an https object that used SSL. So I guess "document the https object" is what this has mutated into. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 14:03 Message: Logged In: YES user_id=3066 It's not at all clear what sort of documentation update is needed. What did you have in mind? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 12:20 Message: Logged In: YES user_id=6380 Please don't Delete requests. Please don't Close them unless you are a project manager (I consider it a SF bug that the submitter can decide to close a bug report if they happen to have admin perms on another project). I've reopened this and recategorized as Doc and assigned to Fred so he can see if the httplib docs need to be updated. ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-09-04 12:16 Message: Logged In: YES user_id=36737 Okay, I'll accept that. Had HTTP documented that it included HTTPS I wouldn't have made the initial mistake. :) Let me know if you want the diff. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:20 Message: Logged In: YES user_id=6380 Isn't SOAP an HTTP application? Then you shouldn't be using urllib, but httplib. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:20 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=458447&group_id=5470 From noreply@sourceforge.net Tue May 20 04:50:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 20:50:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current Message-ID: <E19Hy9R-0007nI-00@sc8-sf-web4.sourceforge.net> Bugs item #740234, was opened at 2003-05-20 03: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=740234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Till Plewe (tpx) Assigned to: Nobody/Anonymous (nobody) Summary: test/build-failures on FreeBSD stable/current Initial Comment: Using snapshot: python_2003-05-19_230000.tar.gz STABLE (FreeBSD 4.8-STABLE #14: Mon Apr 7) CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue May 20) BUILDFAILURE curses does not build; neither on CURRENT nor on STABLE (compiler complaint: /usr/include/ncurses.h:289: conflicting types for `wchar_t' /usr/include/stdlib.h:57: previous declaration of `wchar_t' /usr/include/ncurses.h:292: conflicting types for `wint_t' /usr/include/wchar.h:96: previous declaration of `wint_t' if lines /usr/include/ncurses.h:288-293 #ifndef __wchar_t typedef unsigned long wchar_t; #endif /* __wchar_t */ #ifndef __wint_t typedef long int wint_t; #endif /* __wint_t */ are deleted then curses builds) TESTFAILURES test_re fails on both CURRENT and STABLE test_long test_pow and many more (probably related) tests fail on current See attached file for details ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 From noreply@sourceforge.net Tue May 20 06:00:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 22:00:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-735293 ] Command line timeit.py sets sys.path badly Message-ID: <E19HzEi-0006ww-00@sc8-sf-web3.sourceforge.net> Bugs item #735293, was opened at 2003-05-09 10:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Raymond Hettinger (rhettinger) Summary: Command line timeit.py sets sys.path badly Initial Comment: Running timeit.py from the command line results in the directory containing timeit.py (ie, the standard Python library) being added to sys.path, and the current directory *not* being. To test, create a file mymod.py in the current directory, containing def test(): "Stupid test function" L = [] for i in range(100): L.append(i) Now, execute \Apps\Python\Lib\timeit.py -s "import mymod" "mymod.test()" Result is Traceback (most recent call last): File "\Apps\Python\Lib\timeit.py", line 245, in main x = t.timeit(number) File "\Apps\Python\Lib\timeit.py", line 159, in timeit return self.inner(it, self.timer) File "<timeit-src>", line 3, in inner import mymod ImportError: No module named mymod It's possible to work around this, either by setting PYTHONPATH in the environment to ".", or by adding "import sys; sys.path.insert(0, '.')" to the code in the -s option. But neither is a particularly attractive solution. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-20 00:00 Message: Logged In: YES user_id=80475 Applied as timeit.py 1.12. Thanks for the report and patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-19 18:52 Message: Logged In: YES user_id=80475 I've got it from here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-19 16:01 Message: Logged In: YES user_id=6380 I won't be offended if someone else checks this in and closes this issue. :) ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2003-05-19 11:00 Message: Logged In: YES user_id=113328 This patch does what I'd expect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-16 14:03 Message: Logged In: YES user_id=6380 Good point. Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735293&group_id=5470 From noreply@sourceforge.net Tue May 20 06:16:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 22:16:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-740055 ] optional argument protocol in shelve.open is ignored Message-ID: <E19HzU6-0007OK-00@sc8-sf-web3.sourceforge.net> Bugs item #740055, was opened at 2003-05-19 14:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740055&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fedor Baart (siggyf) >Assigned to: Raymond Hettinger (rhettinger) Summary: optional argument protocol in shelve.open is ignored Initial Comment: In the shelve module in method open() the argument protocol is not passed to the DbfilenameShelf instance. This is easily solved by changing the last line of shelve.py from: return DbfilenameShelf(filename, flag, binary, writeback) into return DbfilenameShelf(filename, flag, protocol, binary, writeback) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-20 00:16 Message: Logged In: YES user_id=80475 Thanks for the report. Fixed. See Lib/shelve.py 1.23 Closing bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740055&group_id=5470 From noreply@sourceforge.net Tue May 20 06:19:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 22:19:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-740026 ] re.finditer() listed as new in 2.2.? Message-ID: <E19HzWk-0007Up-00@sc8-sf-web3.sourceforge.net> Bugs item #740026, was opened at 2003-05-19 13:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: re.finditer() listed as new in 2.2.? Initial Comment: Documentation says re.finditer() is new in 2.2 (http://www.python.org/doc/current/lib/node99.html), but this is not totally correct: [gradha@ws5:0] [~/cms_freeze]$ python Python 2.2.1 (#1, Sep 10 2002, 17:49:17) [GCC 3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.finditer Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'finditer' [0:arpa/g/gradha> /usr/pkg/bin/python2.2 Python 2.2.2 (#1, Mar 13 2003, 22:53:11) [GCC 2.95.3 20010315 (release) (NetBSD nb3)] on netbsd1 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.finditer <function finditer at 0x1201ed218> The first log was produced on an 8.1 Suse default distro. For a moment I wanted to blame Suse, but I thought: "hey, let's blame the documentation!". Please extend that version number to 2.2.2. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-20 00:19 Message: Logged In: YES user_id=80475 I recommend leaving it listed as new in 2.2 since that it the first time that "from sre import *" would find it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-19 20:37 Message: Logged In: YES user_id=33168 This is a bit of a weird case. From looking through CVS, finditer is in sre, but due to a bug it was not exported from re. So import sre ; sre.finditer should work, but from sre import * doesn't. I'm not sure how best to handle this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740026&group_id=5470 From noreply@sourceforge.net Tue May 20 09:11:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 01:11:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-740313 ] inconsist printing of longs Message-ID: <E19I2D8-0003VT-00@sc8-sf-web1.sourceforge.net> Bugs item #740313, was opened at 2003-05-20 08: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=740313&group_id=5470 Category: None Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: inconsist printing of longs Initial Comment: print 2L, 3L prints 2 3 print (2L, 3L) prints (2L, 3L) The stuff that gets printed is different from the repr. I don't think it was like that in Python 2.1. This is a surprising inconsistency and may bite someone sometime. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740313&group_id=5470 From noreply@sourceforge.net Tue May 20 13:14:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 05:14:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-738471 ] csv.Sniffer docs need updating Message-ID: <E19I60M-0002zh-00@sc8-sf-web4.sourceforge.net> Bugs item #738471, was opened at 2003-05-15 15:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738471&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: csv.Sniffer docs need updating Initial Comment: The csv.Sniffer docs need to catch up with the code. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-20 07:14 Message: Logged In: YES user_id=44345 checked in as libcsv.tex 1.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738471&group_id=5470 From noreply@sourceforge.net Tue May 20 13:19:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 05:19:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-740407 ] Can't browse methods and Classes Message-ID: <E19I65h-0006ku-00@sc8-sf-web1.sourceforge.net> Bugs item #740407, was opened at 2003-05-20 12: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=740407&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: hoka (hoka) Assigned to: Nobody/Anonymous (nobody) Summary: Can't browse methods and Classes Initial Comment: If i want to show the method and classes under Browse Python Path i got every time this error: File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 123, in OnTreeItemExpanding self.AddSubList(itemHandle, self.GetSubList (item)) File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 137, in AddSubList self.AddItem(parentHandle, item) File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 140, in AddItem text = self.GetText(item) File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 266, in GetText return self.DelegateCall( item.GetText ) File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 255, in DelegateCall return fn() File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\browseProjects.p y", line 26, in GetText return self.name + self.suffix TypeError: unsupported operand type(s) for +: 'instance' and 'str' win32ui: Exception in OnNotify() handler Greetings Kai ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740407&group_id=5470 From noreply@sourceforge.net Tue May 20 13:39:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 05:39:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-740424 ] MacPython-OS9 distutils breaks on OSX Message-ID: <E19I6OS-0006K6-00@sc8-sf-web2.sourceforge.net> Bugs item #740424, was opened at 2003-05-20 14: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=740424&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-OS9 distutils breaks on OSX Initial Comment: MacPython-OS9 distutils (or actually the underlying mkcwproject package) does not always work on OSX. The problem is that references to the GUSI source tree are relative pathnames to the Python sourcetree with :: in them, and CW (at least CW7) doesn't understand this when running on OSX. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&group_id=5470 From noreply@sourceforge.net Tue May 20 13:43:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 05:43:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-725026 ] Possible OSX module location bug Message-ID: <E19I6TH-0006bj-00@sc8-sf-web2.sourceforge.net> Bugs item #725026, was opened at 2003-04-21 17:12 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725026&group_id=5470 Category: Macintosh Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Submitted By: logistix (logistix) Assigned to: Jack Jansen (jackjansen) Summary: Possible OSX module location bug Initial Comment: I have an app with a testfile 'os.py' that was designed to see if I was searching pythonpath properly (if it found my os.py, it didn't) Running scripts from the directory containing this file has been working fine on Windows, BSD, Linux. An OSX user reported an error trying to run the scripts. Output indicated that site.py was trying to load my os.py instead of the proper one. I can't reproduce it since I don't have OSX, but if someone wants to try: Create a subdirectory under site-packages Create a dummy os.py file Create a dummy test.py file with this directory as the pwd, issue 'python -v test.py' User didn't appear to have anything too funky in sys.path ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-04-21 22:56 Message: Logged In: YES user_id=699438 Here's what he sent me before. Actually, '/Volumes/Other/dev/python' might be the culprit. I'm not sure what working directory the commands were run under. I'll go ahead and forward a link to this bug to him. Unless he has any input, I guess it's "Works for Me". python -v buildWeb.py # /usr/lib/python2.2/site.pyc matches /usr/lib/python2.2/site.py import site # precompiled from /usr/lib/python2.2/site.pyc # ./os.pyc matches ./os.py import os # precompiled from ./os.pyc Ugh! 'import site' failed; traceback: Traceback (most recent call last): File "/usr/lib/python2.2/site.py", line 69, in ? m.__file__ = os.path.abspath(m.__file__) AttributeError: 'module' object has no attribute 'path' Python 2.2 (#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. ... % python -c "import sys;print sys.path" ['', '/Volumes/Other/dev/python', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site- packages'] ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-21 22:23 Message: Logged In: YES user_id=45365 I tried this with all three of - Apple's /usr/bin/python 2.2 - Python 2.3a2+ from CVS - MacPython-OS9 2.3a2+ from CVS None of these see os.py in the current directory. The only thing I can imagine, because you talk about a subdirectory of site-packages, is that the user has a .pth file in site-packages listing the subdirectory. If this isn't the case, ask for the following: - Complete version info (python startup banner) - sys.path value - output of 'python -v test.py'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725026&group_id=5470 From noreply@sourceforge.net Tue May 20 13:45:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 05:45:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-723495 ] runtime_library_dirs broken under OS X Message-ID: <E19I6UJ-0006fq-00@sc8-sf-web2.sourceforge.net> Bugs item #723495, was opened at 2003-04-18 06:41 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470 Category: Distutils Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: runtime_library_dirs broken under OS X Initial Comment: gcc and ld on OSX don't seem to support the -R option, breaking runtime_library_dirs and any distutils installed extensions that require it. I've only checked Python 2.2.2 so far. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-24 15:15 Message: Logged In: YES user_id=45365 Ok, I'll fix if there's a 2.2.3 release upcoming. Thanks for the report! ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-04-24 07:41 Message: Logged In: YES user_id=46639 Yup - that looks like all that is needed to be done. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-18 13:35 Message: Logged In: YES user_id=45365 It looks like backporting the rev. 1.48 fix to Lib/distutils/unixccompiler.py should do the trick. I've attached the patch that should do the trick, if you could try this that would be helpful. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-04-18 13:08 Message: Logged In: YES user_id=46639 Looks like this has been fixed in 2.3a2: if sys.platform[:6] == "darwin": # MacOSX's linker doesn't understand the -R flag at all return "-L" + dir elif compiler[:3] == "gcc" or compiler[:3] == "g++": return "-Wl,-R" + dir else: return "-R" + dir I can't find a bug report or patch on this fix, and I don't know if it is in any 2.2.x branch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-18 10:58 Message: Logged In: YES user_id=45365 Could you elaborate a bit on what breaks, and/or give an example that breaks? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470 From noreply@sourceforge.net Tue May 20 13:50:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 05:50:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-719549 ] Mac OS X painless compilation Message-ID: <E19I6Zs-0008SC-00@sc8-sf-web1.sourceforge.net> Bugs item #719549, was opened at 2003-04-11 10:36 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Pending >Resolution: Invalid Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X painless compilation Initial Comment: under Mac OS X 10.1, python builds without a hitch. I'd think that it would also build under 10.2 as well, although I don't know because I've never built it on 10.2 (I don't have it). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-11 10:52 Message: Logged In: YES user_id=45365 Uhm... As this bug report bascially says "There's no problem", I assume you are referring to something in the documentation (or readme? Something else?) that states that there are problems on OSX. Could you point out where this is, or otherwise clarify your report, please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 From noreply@sourceforge.net Tue May 20 13:57:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 05:57:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-571343 ] Mixing framework and static Pythons Message-ID: <E19I6gO-0000Lq-00@sc8-sf-web1.sourceforge.net> Bugs item #571343, was opened at 2002-06-19 23:49 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571343&group_id=5470 Category: Macintosh Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Mixing framework and static Pythons Initial Comment: We need to check that (on OS X) the error message you get when you attempt to load an extension module in the "wrong" Python (i.e. an extension module built for a static Python into a framework python or vice versa) is of a form understandable to naive users, and not of the "undefined external: foobar" variety. As the situation of having both Pythons on your system may well become commonplace this needs to be addressed in 2.2.X too. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 16:16 Message: Logged In: YES user_id=45365 In Python 2.3 this doesn't seem to be a problem, you always get an error message on import if there is a problem. In 2.2 it is a problem, which can be repeated as follows: - Build and install a framework 2.2.X - Add /Library/Framework/Python.framework/..../lib/python2.2 and .../lib-dynload to sys.path (at the beginning) - run /usr/bin/python (version 2.2) - run import test.regrtest; test.regrtest.main() - witness weird errors culminating in a crash. The reverse (loading non-framework modules into a framework 2.2 python) seems to work okay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571343&group_id=5470 From noreply@sourceforge.net Tue May 20 15:35:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 07:35:26 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-740495 ] API enhancement: poplib.MailReader() Message-ID: <E19I8D8-0001tJ-00@sc8-sf-web4.sourceforge.net> Feature Requests item #740495, was opened at 2003-05-20 16:35 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=740495&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: API enhancement: poplib.MailReader() Initial Comment: When retrieving POP3 mails using poplib, messages are returned as list of lines. Converting them to a email.Messages requires concatinating them into a single string. I suggest writing a little file-like class wrapper which may be used for parsing these type of messages without concatinating the lines first. This wrapper may be exposed in the poplib module. I suggest calling this class 'MailReader', but I would appreciate better naeming :-) If this is of interest, I may volunteer writing this wrapper. See also: Feature Requests item #736494, was opened at 2003-05-12 11:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384681&aid=736494&group_id=25568 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=740495&group_id=5470 From noreply@sourceforge.net Tue May 20 17:18:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 09:18:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-740424 ] MacPython-OS9 distutils breaks on OSX Message-ID: <E19I9oh-0001Mr-00@sc8-sf-web2.sourceforge.net> Bugs item #740424, was opened at 2003-05-20 14:38 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&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-OS9 distutils breaks on OSX Initial Comment: MacPython-OS9 distutils (or actually the underlying mkcwproject package) does not always work on OSX. The problem is that references to the GUSI source tree are relative pathnames to the Python sourcetree with :: in them, and CW (at least CW7) doesn't understand this when running on OSX. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-20 18:18 Message: Logged In: YES user_id=92689 I've observed that (at least with CW8) _all_ pathnames are wrong: they do use /, but the paths are constructed as if they are OS9 paths, ie. the start with the volume name ( /MyHD/rest/of/path ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&group_id=5470 From noreply@sourceforge.net Tue May 20 17:26:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 09:26:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-740313 ] inconsist printing of longs Message-ID: <E19I9x0-0007pF-00@sc8-sf-web4.sourceforge.net> Bugs item #740313, was opened at 2003-05-20 04:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740313&group_id=5470 >Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Later Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: inconsist printing of longs Initial Comment: print 2L, 3L prints 2 3 print (2L, 3L) prints (2L, 3L) The stuff that gets printed is different from the repr. I don't think it was like that in Python 2.1. This is a surprising inconsistency and may bite someone sometime. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-20 12:26 Message: Logged In: YES user_id=31435 This is covered in PEP 237 (unifying ints and longs). repr (long) has a trailing 'L' now, str(long) does not, and when unification is complete neither will have a trailing L. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740313&group_id=5470 From noreply@sourceforge.net Tue May 20 18:11:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 10:11:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-719549 ] Mac OS X painless compilation Message-ID: <E19IAeG-0003on-00@sc8-sf-web2.sourceforge.net> Bugs item #719549, was opened at 2003-04-11 01:36 Message generated for change (Comment added) made by boredzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X painless compilation Initial Comment: under Mac OS X 10.1, python builds without a hitch. I'd think that it would also build under 10.2 as well, although I don't know because I've never built it on 10.2 (I don't have it). ---------------------------------------------------------------------- >Comment By: Mac-arena the Bored Zo (boredzo) Date: 2003-05-20 10:11 Message: Logged In: YES user_id=711099 not exactly. I am referring to the readme for the UNIX python interpreter, but it does not say there is a problem. the relevant portion is below. --- BEGIN Platform specific notes ----------------------- (Some of these may no longer apply. If you find you can build Python on these platforms without the special directions mentioned here, submit a documentation bug report to SourceForge (see Bug Reports above) so we can remove them!) END--- there is a flaw in the Mac OS X entry, though (which I just found looking at it again now): ---BEGIN The tests will crash on both 10.1 and 10.2 with SEGV in test_re and test_sre due to the small default stack size. END--- judging from the rest of that paragraph, it seems that that only applies if you're using tcsh or another *csh when you configure. I used zsh (which comes with both 10.1 and 10.2) and, as I said, it built without a hitch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-11 01:52 Message: Logged In: YES user_id=45365 Uhm... As this bug report bascially says "There's no problem", I assume you are referring to something in the documentation (or readme? Something else?) that states that there are problems on OSX. Could you point out where this is, or otherwise clarify your report, please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 From noreply@sourceforge.net Tue May 20 18:22:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 10:22:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-739424 ] Python2.3b1 install problems on Linux Message-ID: <E19IAow-0002KF-00@sc8-sf-web4.sourceforge.net> Bugs item #739424, was opened at 2003-05-18 05:10 Message generated for change (Comment added) made by macquigg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 install problems on Linux Initial Comment: I'm running Red Hat Linux 8.0, patches fully up to date, with the latest tcl/tk packages installed. Python2.2.1 is running fine, including Tkinter and IDLE. Followed the standard install procedure for Python-2.3.b1 tarball, and Tkinter is now broken. Can't install IDLE. ./configure and make ran OK. ~/Python-2.3b1> make test 227 tests OK 26 skipped 1 unexpected skip on linux2: test_bz2 No module named bz2 ~/Python-2.3b1> make install ... building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -I/usr/X11R6/include -I. -I/home/macquigg/Python-2.3b1/./Include -I/usr/local/include -I/home/macquigg/Python-2.3b1/Include -I/home/macquigg/Python-2.3b1 -c /home/macquigg/Python-2.3b1/Modules/_tkinter.c -o build/temp.linux-i686-2.3/_tkinter.o cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" /usr/include/tk.h:597: parse error before "Bool" ... many more of these parse errors ... ==> Cannot find "Xlib.h" anywhere under /usr/include, /usr/X11R6, or in the Python-2.3b1 distribution. As far as I know, the X11 files have not been altered. Python 2.2.1 still runs OK. Here are the versions on the tcl/tk packages recently downloaded from RedHat. -rw-rw-r-- 1 macquigg macquigg 1570466 May 10 11:36 tcl-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 460160 May 10 13:47 tix-8.2.0b1-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 1390929 May 10 11:40 tk-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 265427 Apr 25 04:54 tkinter-2.2.1-17.i386.rpm More details in the attached logfile. I'll try to keep this configuration together for debugging. - Dave ---------------------------------------------------------------------- >Comment By: David MacQuigg (macquigg) Date: 2003-05-20 10:22 Message: Logged In: YES user_id=676422 Neal: Installing XFree86-devel-4.2.0-72 and rebuilding Python-2.3b1 solved the problem. :>) Tkinter works, and so does IDLEfork-0.9a2. :>) I'm delighted with the new functionality in IDLE. Looks like I'll be giving up on BlackAdder -- *IF* I can get IDLE to play with Qt Designer. That's my next project. I'm also very impressed with Tkinter. It might just pull me away from Qt Designer. As for the currrent Tkinter install problem in 2.3b1, its just a packaging problem that needs to be solved in the .rpm's before the final release. I don't think any normal user will be able to find Xlib.h, or know what package to install. Red Hat was no help at all. There is no way to search their packages for a file you need, inquiries get only an automated response, and they don't appear to be doing their job on checking the stuff they pack into their releases. IDLE won't even start in Red Hat 8.0. I guess it is really up to the developers to check what Red Hat distributes. Keep up the good work. - Dave ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-19 18:00 Message: Logged In: YES user_id=676422 Neal: According to Redhat Network, my package tkinter-2.2.1-17 is installed correctly, including resolution of all dependencies. I did find XFree86-devel-4.2.0-72, and I have scheduled that for installation. I'll let you know if that solves the problem. I'm suspecting a Red Hat problem. They don't do a very good job with checking these packages. Thanks for your help. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-18 13:57 Message: Logged In: YES user_id=33168 You will need the Xlib headers installed to build Tkinter. The RPM package which contains the headers is probably something like XFree86-devel-4-3.0-2. Try installing that package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 From noreply@sourceforge.net Tue May 20 18:28:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 10:28:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-658233 ] gettext.py crash on bogus preamble Message-ID: <E19IAv5-0007B6-00@sc8-sf-web1.sourceforge.net> Bugs item #658233, was opened at 2002-12-24 10:45 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658233&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: gettext.py crash on bogus preamble Initial Comment: If a .po file has the following bogus preamble: msgid "" msgstr "" "Project-Id-Version: Mailman 2.1b6\n" "POT-Creation-Date: Wed Dec 11 07:44:15 2002\n" "PO-Revision-Date: 2002-08-14 01:18:58+00:00\n" "Last-Translator: Ousmane Wilane <wilane@cyg.sn>\n" "Pascal George <george@lyon.inserm.fr>\n" "Language-Team: fr <traduc@traduc.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=iso-8859-15\n" "Content-Transfer-Encoding: quoted-printable\n" "Generated-By: pygettext.py 1.3\n" (notice that Last-Translator has an unexpected second line) then the resulting .mo file will crash Python when a translation is looked up. I got the following exception: Traceback (most recent call last): File "bin/update", line 48, in ? from Mailman import MailList File "/usr/local/mailman/Mailman/MailList.py", line 49, in ? from Mailman.Archiver import Archiver File "/usr/local/mailman/Mailman/Archiver/__init__.py", line 17, in ? from Archiver import * File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 36, in ? from Mailman.i18n import _ File "/usr/local/mailman/Mailman/i18n.py", line 52, in ? set_language() File "/usr/local/mailman/Mailman/i18n.py", line 35, in set_language language) File "/usr/lib/python2.1/gettext.py", line 245, in translation t = _translations.setdefault(key, class_(open(mofile, 'rb'))) File "/usr/lib/python2.1/gettext.py", line 106, in __init__ self._parse(fp) File "/usr/lib/python2.1/gettext.py", line 180, in _parse k, v = item.split(':', 1) ValueError: unpack list of wrong size make: *** [update] Erreur 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658233&group_id=5470 From noreply@sourceforge.net Tue May 20 21:02:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 13:02:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-719549 ] Mac OS X painless compilation Message-ID: <E19IDJO-0002T3-00@sc8-sf-web4.sourceforge.net> Bugs item #719549, was opened at 2003-04-11 10:36 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) >Assigned to: Jack Jansen (jackjansen) Summary: Mac OS X painless compilation Initial Comment: under Mac OS X 10.1, python builds without a hitch. I'd think that it would also build under 10.2 as well, although I don't know because I've never built it on 10.2 (I don't have it). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-20 22:02 Message: Logged In: YES user_id=45365 Thanks for the clarification. It is indeed possible that this was fixed at some point, I will look into it. ---------------------------------------------------------------------- Comment By: Mac-arena the Bored Zo (boredzo) Date: 2003-05-20 19:11 Message: Logged In: YES user_id=711099 not exactly. I am referring to the readme for the UNIX python interpreter, but it does not say there is a problem. the relevant portion is below. --- BEGIN Platform specific notes ----------------------- (Some of these may no longer apply. If you find you can build Python on these platforms without the special directions mentioned here, submit a documentation bug report to SourceForge (see Bug Reports above) so we can remove them!) END--- there is a flaw in the Mac OS X entry, though (which I just found looking at it again now): ---BEGIN The tests will crash on both 10.1 and 10.2 with SEGV in test_re and test_sre due to the small default stack size. END--- judging from the rest of that paragraph, it seems that that only applies if you're using tcsh or another *csh when you configure. I used zsh (which comes with both 10.1 and 10.2) and, as I said, it built without a hitch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-11 10:52 Message: Logged In: YES user_id=45365 Uhm... As this bug report bascially says "There's no problem", I assume you are referring to something in the documentation (or readme? Something else?) that states that there are problems on OSX. Could you point out where this is, or otherwise clarify your report, please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 From noreply@sourceforge.net Tue May 20 22:48:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 14:48:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-719549 ] Mac OS X painless compilation Message-ID: <E19IEyW-0007D7-00@sc8-sf-web4.sourceforge.net> Bugs item #719549, was opened at 2003-04-11 10:36 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Jack Jansen (jackjansen) Summary: Mac OS X painless compilation Initial Comment: under Mac OS X 10.1, python builds without a hitch. I'd think that it would also build under 10.2 as well, although I don't know because I've never built it on 10.2 (I don't have it). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-20 23:48 Message: Logged In: YES user_id=45365 For me the bug still exists, both with zsh and tcsh, so I'm keeping the note in because there is at least one machine where the problem occurs:-) Let me guess: do you have a limit stacksize call in your profile or elsewhere? Or maybe the limit is changed in /etc/profile? The default stack size limit on OSX is 512KB, and this is not enough for test_re. Note that this bug has been fixed in 2.3, but not in 2.2.X. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-20 22:02 Message: Logged In: YES user_id=45365 Thanks for the clarification. It is indeed possible that this was fixed at some point, I will look into it. ---------------------------------------------------------------------- Comment By: Mac-arena the Bored Zo (boredzo) Date: 2003-05-20 19:11 Message: Logged In: YES user_id=711099 not exactly. I am referring to the readme for the UNIX python interpreter, but it does not say there is a problem. the relevant portion is below. --- BEGIN Platform specific notes ----------------------- (Some of these may no longer apply. If you find you can build Python on these platforms without the special directions mentioned here, submit a documentation bug report to SourceForge (see Bug Reports above) so we can remove them!) END--- there is a flaw in the Mac OS X entry, though (which I just found looking at it again now): ---BEGIN The tests will crash on both 10.1 and 10.2 with SEGV in test_re and test_sre due to the small default stack size. END--- judging from the rest of that paragraph, it seems that that only applies if you're using tcsh or another *csh when you configure. I used zsh (which comes with both 10.1 and 10.2) and, as I said, it built without a hitch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-11 10:52 Message: Logged In: YES user_id=45365 Uhm... As this bug report bascially says "There's no problem", I assume you are referring to something in the documentation (or readme? Something else?) that states that there are problems on OSX. Could you point out where this is, or otherwise clarify your report, please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 From noreply@sourceforge.net Wed May 21 00:02:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 16:02:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-740795 ] email package won't parse correct boundary Message-ID: <E19IG7T-0001aU-00@sc8-sf-web4.sourceforge.net> Bugs item #740795, was opened at 2003-05-21 09:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740795&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Nobody/Anonymous (nobody) Summary: email package won't parse correct boundary Initial Comment: the email package appears not to parse a correctly formatted multi-part message. I'll upload the example message, and here is the problem: : helen ; python2.3 Python 2.3b1 (#1, Apr 26 2003, 19:55:12) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import email >>> fd=open('/tmp/m1') >>> msg=email.message_from_file(fd) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.3/email/__init__.py", line 63, in message_from_file return Parser(_class, strict=strict).parse(fp) File "/usr/local/lib/python2.3/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/lib/python2.3/email/Parser.py", line 239, in _parsebody msgobj = self.parsestr(part) File "/usr/local/lib/python2.3/email/Parser.py", line 75, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/usr/local/lib/python2.3/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/lib/python2.3/email/Parser.py", line 245, in _parsebody raise Errors.BoundaryError( email.Errors.BoundaryError: multipart message with no defined boundary >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740795&group_id=5470 From noreply@sourceforge.net Wed May 21 00:45:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 16:45:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-719549 ] Mac OS X painless compilation Message-ID: <E19IGnZ-0004sP-00@sc8-sf-web2.sourceforge.net> Bugs item #719549, was opened at 2003-04-11 01:36 Message generated for change (Comment added) made by boredzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Jack Jansen (jackjansen) Summary: Mac OS X painless compilation Initial Comment: under Mac OS X 10.1, python builds without a hitch. I'd think that it would also build under 10.2 as well, although I don't know because I've never built it on 10.2 (I don't have it). ---------------------------------------------------------------------- >Comment By: Mac-arena the Bored Zo (boredzo) Date: 2003-05-20 16:45 Message: Logged In: YES user_id=711099 I did find one call to ulimit (grep -r ulimit /etc /usr), in rc.common. but all it does is set the size of core dumps, not the stack. nothing is setting the size of the stack. I tried it from zsh 3.0.8 just now (I usually run 4.0.6) and it did SIGSEGV on test_re during a make test. but, I didn't do a make test before, so this might mean nothing. I'll try it in 4.0.6 tonight. now that we have that cleared up... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-20 14:48 Message: Logged In: YES user_id=45365 For me the bug still exists, both with zsh and tcsh, so I'm keeping the note in because there is at least one machine where the problem occurs:-) Let me guess: do you have a limit stacksize call in your profile or elsewhere? Or maybe the limit is changed in /etc/profile? The default stack size limit on OSX is 512KB, and this is not enough for test_re. Note that this bug has been fixed in 2.3, but not in 2.2.X. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-20 13:02 Message: Logged In: YES user_id=45365 Thanks for the clarification. It is indeed possible that this was fixed at some point, I will look into it. ---------------------------------------------------------------------- Comment By: Mac-arena the Bored Zo (boredzo) Date: 2003-05-20 10:11 Message: Logged In: YES user_id=711099 not exactly. I am referring to the readme for the UNIX python interpreter, but it does not say there is a problem. the relevant portion is below. --- BEGIN Platform specific notes ----------------------- (Some of these may no longer apply. If you find you can build Python on these platforms without the special directions mentioned here, submit a documentation bug report to SourceForge (see Bug Reports above) so we can remove them!) END--- there is a flaw in the Mac OS X entry, though (which I just found looking at it again now): ---BEGIN The tests will crash on both 10.1 and 10.2 with SEGV in test_re and test_sre due to the small default stack size. END--- judging from the rest of that paragraph, it seems that that only applies if you're using tcsh or another *csh when you configure. I used zsh (which comes with both 10.1 and 10.2) and, as I said, it built without a hitch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-11 01:52 Message: Logged In: YES user_id=45365 Uhm... As this bug report bascially says "There's no problem", I assume you are referring to something in the documentation (or readme? Something else?) that states that there are problems on OSX. Could you point out where this is, or otherwise clarify your report, please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719549&group_id=5470 From noreply@sourceforge.net Wed May 21 04:51:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 20:51:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-740795 ] email package won't parse correct boundary Message-ID: <E19IKd8-00041Q-00@sc8-sf-web2.sourceforge.net> Bugs item #740795, was opened at 2003-05-21 09:02 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740795&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Nobody/Anonymous (nobody) Summary: email package won't parse correct boundary Initial Comment: the email package appears not to parse a correctly formatted multi-part message. I'll upload the example message, and here is the problem: : helen ; python2.3 Python 2.3b1 (#1, Apr 26 2003, 19:55:12) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import email >>> fd=open('/tmp/m1') >>> msg=email.message_from_file(fd) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.3/email/__init__.py", line 63, in message_from_file return Parser(_class, strict=strict).parse(fp) File "/usr/local/lib/python2.3/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/lib/python2.3/email/Parser.py", line 239, in _parsebody msgobj = self.parsestr(part) File "/usr/local/lib/python2.3/email/Parser.py", line 75, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/usr/local/lib/python2.3/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/lib/python2.3/email/Parser.py", line 245, in _parsebody raise Errors.BoundaryError( email.Errors.BoundaryError: multipart message with no defined boundary >>> ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-05-21 13:51 Message: Logged In: YES user_id=29957 The inner multipart/mixed doesn't have a boundary parameter to it's Content-Type header: > --------------Boundary-00=_75B725CQE5HAM16NTSM1 > Content-Type: Multipart/Mixed > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > > Return-Path: <Postmaster@staff.cs.su.oz.au> > Received: from staff.cs.usyd.edu.au (staff.cs.usyd.edu.au [129.78.8.1]) >From section 5.1.1 of RFC2046: The Content-Type field for multipart entities requires one parameter, "boundary". The boundary delimiter line is then defined as a line consisting entirely of two hyphen characters ("-", decimal value 45) followed by the boundary parameter value from the Content-Type header field, optional linear whitespace, and a terminating CRLF. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740795&group_id=5470 From noreply@sourceforge.net Wed May 21 05:38:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 21:38:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-588756 ] python should obey the FHS Message-ID: <E19ILN6-0003SN-00@sc8-sf-web4.sourceforge.net> Bugs item #588756, was opened at 2002-07-30 13:12 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470 Category: Installation Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: python should obey the FHS Initial Comment: [From: http://bugs.debian.org/134762] FHS Compliance - .py{,c} are architecture independant thus belong in /usr/share The Python manual makes it clear that byte compiled python files are platform independant, and thus belong in arch-independant packages and stored in /usr/share, as per the FHS recommendations for such things. So the request is to store them in <prefix>/share/pythonX.Y. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-20 21:38 Message: Logged In: YES user_id=357491 Will PEP 304 solve your problem? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-31 01:59 Message: Logged In: YES user_id=60903 Ok, I'll give --fhs-prefix a try. some questions: - the lib_python in getpath.c hardcodes lib/pythonX.Y to search for the libraries. Is it enouogh to set PYTHONPATH to pythonX.Y? - who to ask for distutils? are there concerns if a module/library is splitted over two directories? Or should there symlinks from /usr/lib/pythonX.Y to /usr/share/pythonX.Y? - currently there is only one site-packages directory. how should two site-packages be supported (lib and share)? - speaking of etc: this is a configuration file and should belong into the etc hierarchy. should etc be searched before or after the library directories? Python's include files: not all packages separate platform specific headers from generic headers, probably therefore the FHS puts them in /usr/include. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-30 13:51 Message: Logged In: YES user_id=45365 The layouts are similar, but not the same. MacPython-OS9 uses the source tree layout, and Windows-Python too, IIRC. MacPython-OSX in a framework build uses a normal layout, but in a very funny place, with lots of symlinks to make it behave like a framework. I would be very surprised if, say WinCE python or AS/400 python had anything resembling a unix layout. But all these layouts are similar enough that I've never come across a Python where I felt completely lost. I think there's nothing wrong with enabling people to use their preferred layout, if they have a good reason for it, but I would be against enforcing it unless the advantages are clear and universal. And someone has to do the work:-) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-30 13:32 Message: Logged In: YES user_id=163326 Sorry, Matthias. I was confusing the FHS with the Linux Standard Base. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-30 13:24 Message: Logged In: YES user_id=163326 I assume that the Python directory layout is the same on all currently supported platforms by Python. I really don't know enough to be sure - the less that's true, the less my following argument will be valid: There are really two concerns: 1) make Python conform to the FHS 2) make Python behave the same cross-platform (Windows, Unix, Mac, BeOS, OS/2, VMS, AS/400, ...) You can't have both unless you force the FHS directory layout onto all other platforms. I personally think that 2) is a good thing. I welcome the proposal of a configuration option to make Python FHS-compliant, but I think it should not be the default. Btw. you'd probably have to patch distutils, too. Jack said that Pyhon include files should be cross-platform. AFAIK they are, with one exceptions: pyconfig.h. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-30 05:33 Message: Logged In: YES user_id=45365 Well... the usual way in which people implemented sharing between architectures was that the /usr/share hierarchy duplicated the other hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross- platform from an nfs server. That's the architecture the Python install was created for. I have no idea why FHS modified this test-and-tried layout that's been in use for at least 15 years. But: if you really want the other layout, why not submit a fix to configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/ share and if that option is present override the Makefile.pre.in declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR? (Hmm, coming to think of it: it seems rather silly that the FHS puts include files into /usr/include, where they aren't shared... If there's one thing that can be crossplatform it's source code....) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-30 05:33 Message: Logged In: YES user_id=45365 Well... the usual way in which people implemented sharing between architectures was that the /usr/share hierarchy duplicated the other hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross- platform from an nfs server. That's the architecture the Python install was created for. I have no idea why FHS modified this test-and-tried layout that's been in use for at least 15 years. But: if you really want the other layout, why not submit a fix to configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/ share and if that option is present override the Makefile.pre.in declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR? (Hmm, coming to think of it: it seems rather silly that the FHS puts include files into /usr/include, where they aren't shared... If there's one thing that can be crossplatform it's source code....) ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-30 04:30 Message: Logged In: YES user_id=60903 when configured with --prefix=/usr/share and --exec-prefix=/usr, python installs the header files into /usr/share/include/pythonX.Y, which is at least unusual. According to the FHS these files should go into /usr/include/pythonX.Y ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-30 03:52 Message: Logged In: YES user_id=60903 Not yet. --prefix=/foo/share/pythonX.Y would lead to /foo/share/pythonX.Y/lib/pythonX.Y. The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's not possible to install into /foo/share/pythonX.Y, only /foo/share/lib/pythonX.Y is supported. The FHS doesn't specify where to put files inside /usr/share, but most distributions put application specific files directly in /usr/share. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-30 01:35 Message: Logged In: YES user_id=45365 I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough? If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug. If it is impossible to make an FHS-compliant distribution with the current setup: please explain. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-29 23:57 Message: Logged In: YES user_id=60903 The reason given to close the report seems to be invalid. The FHS has nothing to with Debian (except that we follow the FHS). The FHS is targeted at Unix distributions, so it's neither limited to a single distribution nor to Linux distributions in general. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-25 05:41 Message: Logged In: YES user_id=163326 Python runs on dozens of platforms besides Debian Linux. Thus the Linux FHS shouldn't concern Python at all. I'd propose to close this bug as "Invalid". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-03 04:13 Message: Logged In: YES user_id=21627 I think this requires a PEP. A Python package can consist of byte code modules and extension modules; arranging the package loader to find those in different directories is a challenge. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-07-30 13:15 Message: Logged In: YES user_id=60903 FHS: Filesystem Hierarchy Standard http://www.pathname.com/fhs/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=588756&group_id=5470 From noreply@sourceforge.net Wed May 21 05:47:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 21:47:26 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-588825 ] unittest.py, better error message Message-ID: <E19ILVe-0005Rb-00@sc8-sf-web2.sourceforge.net> Feature Requests item #588825, was opened at 2002-07-30 15:29 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Heimann (stefanheimann) >Assigned to: Nobody/Anonymous (nobody) Summary: unittest.py, better error message Initial Comment: These two methods of the class TestCase are not very good: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '!=' operator. """ if first != second: raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) def failIfEqual(self, first, second, msg=None): """Fail if the two objects are equal as determined by the '==' operator. """ if first == second: raise self.failureException, \ (msg or '%s == %s' % (`first`, `second`)) The first thing is that you should print the difference of the given values like that: '<%s> == <%s>' % (`first`, `second`) The < and > delimits the string and so is is easier to detect where the string starts and where it ends. The second thing is that I would really like to see the two values that are (not) equal even if I provide a message. Maybe its better to raise the exception like that: if msg is not None: msg += ' Expected: <%s>, is: <%s>' % (first, second) raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) bye Stefan ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-20 21:47 Message: Logged In: YES user_id=357491 I am making this an RFE since it is just a suggestion and not a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-18 15:19 Message: Logged In: YES user_id=80475 Steve, would you like these implemented or left as is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 From noreply@sourceforge.net Wed May 21 05:52:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 21:52:44 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-602893 ] cgitb tracebacks not accessible Message-ID: <E19ILam-0003nQ-00@sc8-sf-web4.sourceforge.net> Feature Requests item #602893, was opened at 2002-08-31 11:02 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=602893&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Silas S. Brown (ssb22) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb tracebacks not accessible Initial Comment: The cgitb tracebacks use colour ALONE to highlight which line caused the exception. This doesn't show up on text-only browsers such as Lynx, and it is not helpful to blind people or those with similar special needs. These people have to count the lines, or set "context" to 1, or look at the HTML source to see the real traceback in the comments. It would be most helpful if there were at least an option to indicate the line that caused the error in some additional way (as well as the colour), such as by highlighting it with some punctuation character to the left of the line number. (Python 2.2.1 under Debian Woody) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=602893&group_id=5470 From noreply@sourceforge.net Wed May 21 06:15:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 22:15:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: <E19ILwR-0001QL-00@sc8-sf-web1.sourceforge.net> Bugs item #604716, was opened at 2002-09-04 13:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-20 22:15 Message: Logged In: YES user_id=357491 Are people still interested in this? ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-05 17:04 Message: Logged In: YES user_id=670441 I went ahead and coded up a patch based on the discussion below. It implements Py_INCREF_N and Py_DECREF_N (just for symmetry, not sure if anyone needs it) and puts the new INCREF to use in list_repeat. Also, list_repeat makes special cases of 0's. I tested with python like that described below: from time import clock niter = 10 iterations = [None] * niter start, end = 0, 7 for length in range(start, end): l = [None]*length if length == 0: multiplier = 10000000 else: multiplier = 1000000/length start = clock() for i in iterations: lmult = l*multiplier total = clock() - start print "for list length %d, time %e" % (length, total) I tested the patch on different list sizes, 0-7, 200-207, 1000-1007, and found about an 8% speed increase in all cases (except the 0 case of course, 100% speedup). I was surprised to find the debug build didn't differ in improvment from the patch. I also tried implementing the inner loop as memcpy, but found the results only started to improve noticably at list sizes of 1000 or so, and there was a sizable performance hit at small sizes of more than 20%. This might be worth including for very large lists as a separate case, but I think it's pretty rare to repeat a list that size. Let me know what you think of it or what changes you want. (I can't attach it in sourceforge so I'm pasting it in): Index: Objects/listobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/listobject.c,v retrieving revision 2.145 diff -c -r2.145 listobject.c *** Objects/listobject.c 2 Jan 2003 20:51:08 -0000 2.145 --- Objects/listobject.c 6 Feb 2003 00:48:46 -0000 *************** *** 415,436 **** list_repeat(PyListObject *a, int n) { int i, j; ! int size; PyListObject *np; ! PyObject **p; if (n < 0) n = 0; ! size = a->ob_size * n; ! if (n && size/n != a->ob_size) return PyErr_NoMemory(); np = (PyListObject *) PyList_New(size); if (np == NULL) return NULL; p = np->ob_item; for (i = 0; i < n; i++) { ! for (j = 0; j < a->ob_size; j++) { ! *p = a->ob_item[j]; ! Py_INCREF(*p); p++; } } --- 415,441 ---- list_repeat(PyListObject *a, int n) { int i, j; ! int size, ob_size; PyListObject *np; ! PyObject **p, **ob_item; if (n < 0) n = 0; ! ob_size = a->ob_size; ! if (n == 0 || ob_size == 0) ! return PyList_New(0); ! size = ob_size * n; ! if (size/n != ob_size) return PyErr_NoMemory(); np = (PyListObject *) PyList_New(size); if (np == NULL) return NULL; p = np->ob_item; + ob_item = a->ob_item; + for (i = 0; i < ob_size; i++) + Py_INCREF_N(ob_item[i], n); for (i = 0; i < n; i++) { ! for (j = 0; j < ob_size; j++) { ! *p = ob_item[j]; p++; } } Index: Include/object.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/object.h,v retrieving revision 2.112 diff -c -r2.112 object.h *** Include/object.h 17 Nov 2002 17:52:44 -0000 2.112 --- Include/object.h 6 Feb 2003 00:48:51 -0000 *************** *** 526,532 **** --- 526,534 ---- PyAPI_FUNC(void) _Py_NegativeRefcount(const char *fname, int lineno, PyObject *op); #define _Py_INC_REFTOTAL _Py_RefTotal++ + #define _Py_INC_REFTOTAL_N(N) _Py_RefTotal += (N) #define _Py_DEC_REFTOTAL _Py_RefTotal-- + #define _Py_DEC_REFTOTAL_N(N) _Py_RefTotal -= (N) #define _Py_REF_DEBUG_COMMA , #define _Py_CHECK_REFCNT(OP) \ { if ((OP)->ob_refcnt < 0) \ *************** *** 535,541 **** --- 537,545 ---- } #else #define _Py_INC_REFTOTAL + #define _Py_INC_REFTOTAL_N(N) #define _Py_DEC_REFTOTAL + #define _Py_DEC_REFTOTAL_N(N) #define _Py_REF_DEBUG_COMMA #define _Py_CHECK_REFCNT(OP) /* a semicolon */; #endif /* Py_REF_DEBUG */ *************** *** 580,591 **** --- 584,607 ---- _Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \ (op)->ob_refcnt++) + #define Py_INCREF_N(op, N) ( \ + _Py_INC_REFTOTAL_N(N) _Py_REF_DEBUG_COMMA \ + (op)->ob_refcnt += (N)) + #define Py_DECREF(op) \ if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ --(op)->ob_refcnt != 0) \ _Py_CHECK_REFCNT(op) \ else \ _Py_Dealloc((PyObject *)(op)) + + #define Py_DECREF_N(op, N) ( \ + if (_Py_DEC_REFTOTAL_N(N) _Py_REF_DEBUG_COMMA \ + ((op)->ob_refcnt -= (N)) != 0) \ + _Py_CHECK_REFCNT(op) \ + else \ + _Py_Dealloc((PyObject *)(op)) + /* Macros to use in case the object pointer may be NULL: */ #define Py_XINCREF(op) if ((op) == NULL) ; else Py_INCREF(op) ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-10-12 08:12 Message: Logged In: YES user_id=292741 Sure, the loop inversion is not a big deal. There are two slightly larger issues, though: (1) O(n) time for []*n seems worth fixing; I noticed Guido was just in there adding a size check, and bumping into the [..]*0 case (descr. in #622091 as []*5 ), so another little edit won't hurt right? I suggest changing size = a->ob_size * n; if (n && size/n != a->ob_size) return PyErr_NoMemory(); to size = a->ob_size * n; if( size == 0 ) return PyList_New(0); if (size/n != a->ob_size) return PyErr_NoMemory(); which is hopefully correct by inductive inspection :-) (2) If there is any merit seen in introducing Py_INCREF_N to object.h for future use, this seems as good a place as any to break ground. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-04 13:16 Message: Logged In: YES user_id=80475 It's starting to look as if any sort of optimization effort will take more human time to create, test, and review than it could ever save in computer time. Can this be closed? ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-12 14:13 Message: Logged In: YES user_id=292741 OK, i'll try that when I have time. The problem is, you can't do [None]*1000000 over and over again for 10 seconds unless you also destroy the lists, there isn't enough RAM - and I was trying not to count the dispose time, which of course is also dependent on the list length. I was calling calling clock() immediately before and after the operation, and accumulating the differences, thus excluding the rest of the loop with the list delete. any uncertainty in clock() should in principle average out over a lot of reps. For what it's worth, the results were reasonably repeatable from run to run (maybe 5%) and very linear with respect to changing the '*1000000' factor. I know i'm effectively timing one call to clock() as part of the timed code; but that won't change with the list size and can thus be factored out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 09:43 Message: Logged In: YES user_id=21627 Please don't invoke clock() twice per iteration. The standard timing procedure is iterations = [None] * niter start = clock() for i in iterations: actions_to_time total = clock() - start That way, you don't measure the time it takes to create the range object. Also, don't trust any measurements that have a total time of less then 10s (running it for a minute is even better). With this algorithm, please re-report the two totals, and the number of iterations. Run it several times in a row, to see how results vary. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 16:10 Message: Logged In: YES user_id=292741 using this test code, and changing the 1000000, I have found that it adds an additional 40 nsec for each additional copy of the None. This doesn't change noticeably when I add the 'improvement'. If I change it to []*whatever, then the old implementation needs 5 ns extra for each non-copy (and the new one isn't sensitive). This is telling me that most of the time in the [None]*lots is in the PyList_New() to get the list. So I went and made a variant of PyList_New which doesn't clear the list, and found that [None]*1000000 takes 22msec instead of the 40 it used to take. This doesn't make too much sense, looking at the code; maybe cache effects. Time to go home now... ------------------------- def timeit(): from time import clock t0 = clock() tin = 0 niter = 50 for i in range(niter): ta,p,tb = clock(),[None]*1000000,clock() tin += tb-ta p = 0 # deallocate list t0 = clock()-t0 print "avg. time = ", tin/niter print "avg. overhead = ", t0/niter timeit() --------------------- ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 12:16 Message: Logged In: YES user_id=80475 Yes, I looked at the all-at-once memcpy approach but found that MVC++'s memcpy() was too smart and would not use the buffer overlap as intended. This is a dead-end. Using memcpy() in a loop as I suggested will work fine. Neal implemented a number of micro-optimizations using this and/or memchr(). You've already hit on the common case and best speed-up by special casing length one and by py_incref_n. Go for it. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 11:41 Message: Logged In: YES user_id=292741 [ sound effects: can opener, worms... ] ;-) Use of memcpy/memset is a whole other issue- see below What you've got there doesn't help for the case I mention. If you do []*100000, you get 100000 calls to memcpy with size = 0, and if you do [None]*100000, 100000 calls to memcpy with size = 4; this could easily wind up being even slower. The point is to reduce the number of times the inner loop quits and the outer loop runs; the actual code in the inner loop will run the same number of times regardless (although *p = regvar is faster than *p = ptr->a[j] ); it's the loop overhead (instruction queue flushes, etc) that make a difference here. Bear in mind too that 'j < a->ob_size' will load a->ob_size on each loop, if the compiler can't be sure you didn't write it via *p [yes i''ve spent too much time looking at C compiler output. real-time DSP applications mostly]. Many compilers do intrinsic memcpy so that there's no call, but since the length of the copy is not fixed, code still needs to be generated to test the length, and you wind up being no better than the original for short source lists. Regarding the use of memcpy/memset in general; these could be applied in a lot of cases - making a list slice, filling a new list with null's etc - and on some machines they make a big difference to the speed of the operation. Compared to the time spent later working on that list, it may not show up much in the end. Having said that, I've done some python apps which process, say, 20Mbytes of binary floating-point data in about 12 seconds, by avoiding any python looping ( using Numeric and image file read/writes). In this kind of thing, a faster slice copy can make difference. I'm assuming the programmer would rather not have the marginal speedup of these routines, if it poses even a small possibility of creating portability issues on some weird machine, and this is a pretty wise policy on a project of this nature. I suspect any machine where memcpy doesn't work in this context would also fail to work with python's polymorphism and general memory management, but whatever. A really good way to make a lot of copies of a small list is to make the first copy, then do a single memcpy( p, p+size, (n-1)*size * sizeof(*p) ) which 'rolls' the same memory over and over. No loops (except within memcpy and the assumption is that that one is as good as it gets). But this may be even less portable than the other uses of memcpy, because it makes assumptions about how memcpy handles overlapped transfers. E.g., machines with a lot of registers could do a bunch of reads and a bunch of writes to help out the cache, thus breaking this for small input lists. And yes, I'll report some speedup results when I have some. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 11:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 02:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 18:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Wed May 21 06:50:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 22:50:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files Message-ID: <E19IMUa-00025x-00@sc8-sf-web3.sourceforge.net> Bugs item #602345, was opened at 2002-08-30 04:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Neal Norwitz (nnorwitz) Summary: option for not writing .py[co] files Initial Comment: [destilled from http://bugs.debian.org/96111] Currently python tries to write the .py[co] files even in situations, where it will fail, like on read-only mounted file systems. In other situations I don't want python trying to write the compiled files, i.e. having installed the modules as root as part of a distribution, compiled them correctly, there is no need to write them. Or compiling .py files which are configuration files. Is it reasonable to add an option to python (--dont-write-compiled-files) to the interpreter, which doesn't write them? This would not affect existing code at all. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-20 22:50 Message: Logged In: YES user_id=357491 PEP 304 now handles this situation. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-12 13:39 Message: Logged In: YES user_id=33168 You are correct about the patch being incomplete. I still have to do all the doc. I hadn't thought about an env't variable or variable in sys. Both are certainly reasonable. I will update the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-12 11:47 Message: Logged In: YES user_id=21627 The patch looks good, but is surely incomplete: there should be patches to the documentation, in particular to the man page. It might be also desirable to parallel this option with an environment variable, and/or to expose it writable through the sys module. With the environment variable, people could run Python scripts that won't create .pyc files (as #! /usr/bin/env python does not allow for further command line options). With the API, certain applications could declare that they never want to write .pyc files as they expect to run in parallel with itself, and might cause .pyc conflicts. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 08:39 Message: Logged In: YES user_id=6380 I think it's a good idea, but please use a single upper case letter for the option. Python doesn't support long options and I'm not about to start doing so. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 16:30 Message: Logged In: YES user_id=33168 Guido, do you think this is a good idea? If so, assign back to me and I'll work up a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 From noreply@sourceforge.net Wed May 21 06:56:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 22:56:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-610401 ] linuxaudiodev not documented Message-ID: <E19IMai-0002aU-00@sc8-sf-web1.sourceforge.net> Bugs item #610401, was opened at 2002-09-17 00:31 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610401&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: linuxaudiodev not documented Initial Comment: Hi, I've just discovered that there is a linuxaudiodev module in python, which is not mentioned in the standard library documentation. While it looks a lot like sunaudiodev, which is documented, the sunaudiodev docs cannot be used directly because both modules don't share the same interfaces. For instance open() does not accept the same parameters, and the audio device objects don't have the same methods. Having some docstrings in the linuxaudiodev module could help a lot. Cheers, Alexandre ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-20 22:56 Message: Logged In: YES user_id=357491 Should we close this since linuxaudiodev has been deprecated? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 17:02 Message: Logged In: YES user_id=33168 Note: linuxaudiodev has been deprecated. ossaudiodev is the module which should be documented. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-17 07:05 Message: Logged In: YES user_id=3066 There's also an "audiodev" module, which masks the differences between the SGI interface (the "al" and "AL" modules) and the Solaris interface ("sunaudiodev"). Probably the right thing would be for someone who understands the linuxaudiodev interface to extend the "audiodev" module to support Linux as well, and then we could document the audiodev interface instead, and treat the others as implementation details. But I know almost nothing about audio beyond how to stick a CD in a CD player. Contributions are welcome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610401&group_id=5470 From noreply@sourceforge.net Wed May 21 06:54:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 22:54:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-602444 ] non greedy match bug Message-ID: <E19IMYX-0007Ii-00@sc8-sf-web2.sourceforge.net> Bugs item #602444, was opened at 2002-08-30 07:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602444&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Robert Roy (rjroy) Assigned to: Fredrik Lundh (effbot) Summary: non greedy match bug Initial Comment: When using the following re to extract all objects from a PDF file, I get a maximum recursion limit exceeded error. Attached is a pdf file that will reproduce the error. If I do import pre as re, it works fine. platform is Win2k, Python 2.2.1 build #34 ####### import re GETOBJECT = re.compile(r'\d+\s+\d+\s+obj.+?endobj', re.I|re.S|re.M) pdf = open('userguide.pdf', 'rb').read() all = GETOBJECT.findall(pdf) print len(all) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-20 22:54 Message: Logged In: YES user_id=357491 Closing this since hitting the recursion limit is not a bug. ---------------------------------------------------------------------- Comment By: Robert Roy (rjroy) Date: 2003-02-14 10:56 Message: Logged In: YES user_id=352797 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602444&group_id=5470 From noreply@sourceforge.net Wed May 21 06:59:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 20 May 2003 22:59:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: <E19IMda-0007Sa-00@sc8-sf-web2.sourceforge.net> Bugs item #604716, was opened at 2002-09-04 15:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 00:59 Message: Logged In: YES user_id=80475 Wrapping this one up by applying the simplest version of the patch that gets a measurable improvement (from 255 usec to 224 usec measured by python timeit.py "[None] * 10000" See Objects/listobject.c 2.153 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 00:15 Message: Logged In: YES user_id=357491 Are people still interested in this? ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-05 20:04 Message: Logged In: YES user_id=670441 I went ahead and coded up a patch based on the discussion below. It implements Py_INCREF_N and Py_DECREF_N (just for symmetry, not sure if anyone needs it) and puts the new INCREF to use in list_repeat. Also, list_repeat makes special cases of 0's. I tested with python like that described below: from time import clock niter = 10 iterations = [None] * niter start, end = 0, 7 for length in range(start, end): l = [None]*length if length == 0: multiplier = 10000000 else: multiplier = 1000000/length start = clock() for i in iterations: lmult = l*multiplier total = clock() - start print "for list length %d, time %e" % (length, total) I tested the patch on different list sizes, 0-7, 200-207, 1000-1007, and found about an 8% speed increase in all cases (except the 0 case of course, 100% speedup). I was surprised to find the debug build didn't differ in improvment from the patch. I also tried implementing the inner loop as memcpy, but found the results only started to improve noticably at list sizes of 1000 or so, and there was a sizable performance hit at small sizes of more than 20%. This might be worth including for very large lists as a separate case, but I think it's pretty rare to repeat a list that size. Let me know what you think of it or what changes you want. (I can't attach it in sourceforge so I'm pasting it in): Index: Objects/listobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/listobject.c,v retrieving revision 2.145 diff -c -r2.145 listobject.c *** Objects/listobject.c 2 Jan 2003 20:51:08 -0000 2.145 --- Objects/listobject.c 6 Feb 2003 00:48:46 -0000 *************** *** 415,436 **** list_repeat(PyListObject *a, int n) { int i, j; ! int size; PyListObject *np; ! PyObject **p; if (n < 0) n = 0; ! size = a->ob_size * n; ! if (n && size/n != a->ob_size) return PyErr_NoMemory(); np = (PyListObject *) PyList_New(size); if (np == NULL) return NULL; p = np->ob_item; for (i = 0; i < n; i++) { ! for (j = 0; j < a->ob_size; j++) { ! *p = a->ob_item[j]; ! Py_INCREF(*p); p++; } } --- 415,441 ---- list_repeat(PyListObject *a, int n) { int i, j; ! int size, ob_size; PyListObject *np; ! PyObject **p, **ob_item; if (n < 0) n = 0; ! ob_size = a->ob_size; ! if (n == 0 || ob_size == 0) ! return PyList_New(0); ! size = ob_size * n; ! if (size/n != ob_size) return PyErr_NoMemory(); np = (PyListObject *) PyList_New(size); if (np == NULL) return NULL; p = np->ob_item; + ob_item = a->ob_item; + for (i = 0; i < ob_size; i++) + Py_INCREF_N(ob_item[i], n); for (i = 0; i < n; i++) { ! for (j = 0; j < ob_size; j++) { ! *p = ob_item[j]; p++; } } Index: Include/object.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Include/object.h,v retrieving revision 2.112 diff -c -r2.112 object.h *** Include/object.h 17 Nov 2002 17:52:44 -0000 2.112 --- Include/object.h 6 Feb 2003 00:48:51 -0000 *************** *** 526,532 **** --- 526,534 ---- PyAPI_FUNC(void) _Py_NegativeRefcount(const char *fname, int lineno, PyObject *op); #define _Py_INC_REFTOTAL _Py_RefTotal++ + #define _Py_INC_REFTOTAL_N(N) _Py_RefTotal += (N) #define _Py_DEC_REFTOTAL _Py_RefTotal-- + #define _Py_DEC_REFTOTAL_N(N) _Py_RefTotal -= (N) #define _Py_REF_DEBUG_COMMA , #define _Py_CHECK_REFCNT(OP) \ { if ((OP)->ob_refcnt < 0) \ *************** *** 535,541 **** --- 537,545 ---- } #else #define _Py_INC_REFTOTAL + #define _Py_INC_REFTOTAL_N(N) #define _Py_DEC_REFTOTAL + #define _Py_DEC_REFTOTAL_N(N) #define _Py_REF_DEBUG_COMMA #define _Py_CHECK_REFCNT(OP) /* a semicolon */; #endif /* Py_REF_DEBUG */ *************** *** 580,591 **** --- 584,607 ---- _Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \ (op)->ob_refcnt++) + #define Py_INCREF_N(op, N) ( \ + _Py_INC_REFTOTAL_N(N) _Py_REF_DEBUG_COMMA \ + (op)->ob_refcnt += (N)) + #define Py_DECREF(op) \ if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ --(op)->ob_refcnt != 0) \ _Py_CHECK_REFCNT(op) \ else \ _Py_Dealloc((PyObject *)(op)) + + #define Py_DECREF_N(op, N) ( \ + if (_Py_DEC_REFTOTAL_N(N) _Py_REF_DEBUG_COMMA \ + ((op)->ob_refcnt -= (N)) != 0) \ + _Py_CHECK_REFCNT(op) \ + else \ + _Py_Dealloc((PyObject *)(op)) + /* Macros to use in case the object pointer may be NULL: */ #define Py_XINCREF(op) if ((op) == NULL) ; else Py_INCREF(op) ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-10-12 10:12 Message: Logged In: YES user_id=292741 Sure, the loop inversion is not a big deal. There are two slightly larger issues, though: (1) O(n) time for []*n seems worth fixing; I noticed Guido was just in there adding a size check, and bumping into the [..]*0 case (descr. in #622091 as []*5 ), so another little edit won't hurt right? I suggest changing size = a->ob_size * n; if (n && size/n != a->ob_size) return PyErr_NoMemory(); to size = a->ob_size * n; if( size == 0 ) return PyList_New(0); if (size/n != a->ob_size) return PyErr_NoMemory(); which is hopefully correct by inductive inspection :-) (2) If there is any merit seen in introducing Py_INCREF_N to object.h for future use, this seems as good a place as any to break ground. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-04 15:16 Message: Logged In: YES user_id=80475 It's starting to look as if any sort of optimization effort will take more human time to create, test, and review than it could ever save in computer time. Can this be closed? ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-12 16:13 Message: Logged In: YES user_id=292741 OK, i'll try that when I have time. The problem is, you can't do [None]*1000000 over and over again for 10 seconds unless you also destroy the lists, there isn't enough RAM - and I was trying not to count the dispose time, which of course is also dependent on the list length. I was calling calling clock() immediately before and after the operation, and accumulating the differences, thus excluding the rest of the loop with the list delete. any uncertainty in clock() should in principle average out over a lot of reps. For what it's worth, the results were reasonably repeatable from run to run (maybe 5%) and very linear with respect to changing the '*1000000' factor. I know i'm effectively timing one call to clock() as part of the timed code; but that won't change with the list size and can thus be factored out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 11:43 Message: Logged In: YES user_id=21627 Please don't invoke clock() twice per iteration. The standard timing procedure is iterations = [None] * niter start = clock() for i in iterations: actions_to_time total = clock() - start That way, you don't measure the time it takes to create the range object. Also, don't trust any measurements that have a total time of less then 10s (running it for a minute is even better). With this algorithm, please re-report the two totals, and the number of iterations. Run it several times in a row, to see how results vary. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 18:10 Message: Logged In: YES user_id=292741 using this test code, and changing the 1000000, I have found that it adds an additional 40 nsec for each additional copy of the None. This doesn't change noticeably when I add the 'improvement'. If I change it to []*whatever, then the old implementation needs 5 ns extra for each non-copy (and the new one isn't sensitive). This is telling me that most of the time in the [None]*lots is in the PyList_New() to get the list. So I went and made a variant of PyList_New which doesn't clear the list, and found that [None]*1000000 takes 22msec instead of the 40 it used to take. This doesn't make too much sense, looking at the code; maybe cache effects. Time to go home now... ------------------------- def timeit(): from time import clock t0 = clock() tin = 0 niter = 50 for i in range(niter): ta,p,tb = clock(),[None]*1000000,clock() tin += tb-ta p = 0 # deallocate list t0 = clock()-t0 print "avg. time = ", tin/niter print "avg. overhead = ", t0/niter timeit() --------------------- ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:16 Message: Logged In: YES user_id=80475 Yes, I looked at the all-at-once memcpy approach but found that MVC++'s memcpy() was too smart and would not use the buffer overlap as intended. This is a dead-end. Using memcpy() in a loop as I suggested will work fine. Neal implemented a number of micro-optimizations using this and/or memchr(). You've already hit on the common case and best speed-up by special casing length one and by py_incref_n. Go for it. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 13:41 Message: Logged In: YES user_id=292741 [ sound effects: can opener, worms... ] ;-) Use of memcpy/memset is a whole other issue- see below What you've got there doesn't help for the case I mention. If you do []*100000, you get 100000 calls to memcpy with size = 0, and if you do [None]*100000, 100000 calls to memcpy with size = 4; this could easily wind up being even slower. The point is to reduce the number of times the inner loop quits and the outer loop runs; the actual code in the inner loop will run the same number of times regardless (although *p = regvar is faster than *p = ptr->a[j] ); it's the loop overhead (instruction queue flushes, etc) that make a difference here. Bear in mind too that 'j < a->ob_size' will load a->ob_size on each loop, if the compiler can't be sure you didn't write it via *p [yes i''ve spent too much time looking at C compiler output. real-time DSP applications mostly]. Many compilers do intrinsic memcpy so that there's no call, but since the length of the copy is not fixed, code still needs to be generated to test the length, and you wind up being no better than the original for short source lists. Regarding the use of memcpy/memset in general; these could be applied in a lot of cases - making a list slice, filling a new list with null's etc - and on some machines they make a big difference to the speed of the operation. Compared to the time spent later working on that list, it may not show up much in the end. Having said that, I've done some python apps which process, say, 20Mbytes of binary floating-point data in about 12 seconds, by avoiding any python looping ( using Numeric and image file read/writes). In this kind of thing, a faster slice copy can make difference. I'm assuming the programmer would rather not have the marginal speedup of these routines, if it poses even a small possibility of creating portability issues on some weird machine, and this is a pretty wise policy on a project of this nature. I suspect any machine where memcpy doesn't work in this context would also fail to work with python's polymorphism and general memory management, but whatever. A really good way to make a lot of copies of a small list is to make the first copy, then do a single memcpy( p, p+size, (n-1)*size * sizeof(*p) ) which 'rolls' the same memory over and over. No loops (except within memcpy and the assumption is that that one is as good as it gets). But this may be even less portable than the other uses of memcpy, because it makes assumptions about how memcpy handles overlapped transfers. E.g., machines with a lot of registers could do a bunch of reads and a bunch of writes to help out the cache, thus breaking this for small input lists. And yes, I'll report some speedup results when I have some. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 13:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 04:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 20:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Wed May 21 09:13:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 01:13:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-736407 ] Problem With email.MIMEText Package Message-ID: <E19IOiv-0007ZV-00@sc8-sf-web3.sourceforge.net> Bugs item #736407, was opened at 2003-05-12 09:41 Message generated for change (Comment added) made by judasiscariot 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: Open 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: John Abel (judasiscariot) Date: 2003-05-21 08: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 19: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 14: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 09: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 15: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@sourceforge.net Wed May 21 09:16:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 01:16:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-736407 ] Problem With email.MIMEText Package Message-ID: <E19IOlz-0007il-00@sc8-sf-web3.sourceforge.net> Bugs item #736407, was opened at 2003-05-12 09:41 Message generated for change (Comment added) made by judasiscariot 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: Open 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: John Abel (judasiscariot) Date: 2003-05-21 08: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 08: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 19: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 14: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 09: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 15: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@sourceforge.net Wed May 21 11:35:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 03:35:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-741029 ] HTMLParser -- possible bug in handle_comment Message-ID: <E19IQwV-0001RB-00@sc8-sf-web2.sourceforge.net> Bugs item #741029, was opened at 2003-05-21 00:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741029&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott Israel (scott_israel) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser -- possible bug in handle_comment Initial Comment: >>> import HTMLParser >>> class Parser(HTMLParser.HTMLParser): def __init__(self): HTMLParser.HTMLParser.__init__ (self) def handle_data(self,data): print 'DATA: %s' % data def handle_comment(self,comment): print 'COMMENT: %s' % comment >>> test3='<STYLE><!-- This is a comment --> </STYLE>' >>> p=Parser() >>> p.feed(test3) DATA: <!-- This is a comment --> Is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741029&group_id=5470 From noreply@sourceforge.net Wed May 21 12:04:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 04:04:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-740795 ] email package won't parse correct boundary Message-ID: <E19IROj-0001A1-00@sc8-sf-web4.sourceforge.net> Bugs item #740795, was opened at 2003-05-21 09:02 Message generated for change (Comment added) made by pierslauder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740795&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Nobody/Anonymous (nobody) Summary: email package won't parse correct boundary Initial Comment: the email package appears not to parse a correctly formatted multi-part message. I'll upload the example message, and here is the problem: : helen ; python2.3 Python 2.3b1 (#1, Apr 26 2003, 19:55:12) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import email >>> fd=open('/tmp/m1') >>> msg=email.message_from_file(fd) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.3/email/__init__.py", line 63, in message_from_file return Parser(_class, strict=strict).parse(fp) File "/usr/local/lib/python2.3/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/lib/python2.3/email/Parser.py", line 239, in _parsebody msgobj = self.parsestr(part) File "/usr/local/lib/python2.3/email/Parser.py", line 75, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/usr/local/lib/python2.3/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/lib/python2.3/email/Parser.py", line 245, in _parsebody raise Errors.BoundaryError( email.Errors.BoundaryError: multipart message with no defined boundary >>> ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2003-05-21 21:04 Message: Logged In: YES user_id=196212 Apologies for missing the mal-formed Multipart/Mixed section. As the message is mal-formed, I agree the parser is behaving correctly. I'll close the bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-05-21 13:51 Message: Logged In: YES user_id=29957 The inner multipart/mixed doesn't have a boundary parameter to it's Content-Type header: > --------------Boundary-00=_75B725CQE5HAM16NTSM1 > Content-Type: Multipart/Mixed > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > > Return-Path: <Postmaster@staff.cs.su.oz.au> > Received: from staff.cs.usyd.edu.au (staff.cs.usyd.edu.au [129.78.8.1]) >From section 5.1.1 of RFC2046: The Content-Type field for multipart entities requires one parameter, "boundary". The boundary delimiter line is then defined as a line consisting entirely of two hyphen characters ("-", decimal value 45) followed by the boundary parameter value from the Content-Type header field, optional linear whitespace, and a terminating CRLF. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740795&group_id=5470 From noreply@sourceforge.net Wed May 21 15:56:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 07:56:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-741171 ] pdb crashes when enabling a non-existing breakpoint Message-ID: <E19IV18-0002Dp-00@sc8-sf-web1.sourceforge.net> Bugs item #741171, was opened at 2003-05-21 16: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=741171&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Heike C. Zimmerer (hcz) Assigned to: Nobody/Anonymous (nobody) Summary: pdb crashes when enabling a non-existing breakpoint Initial Comment: pdb exits when enabling a non-existing breakpoint. This happens on 2.2.2 and on 2.3a0: $ echo > x.py $ pdb x.py > <string>(0)?() (Pdb) enable 1 Traceback (most recent call last): File "/usr/lib/python2.2/pdb.py", line 959, in ? run('execfile(' + `filename` + ')') [...] File "/usr/lib/python2.2/cmd.py", line 200, in onecmd return func(arg) File "/usr/lib/python2.2/pdb.py", line 370, in do_enable bp = bdb.Breakpoint.bpbynumber[int(i)] IndexError: list index out of range $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741171&group_id=5470 From noreply@sourceforge.net Wed May 21 18:35:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 10:35:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-734869 ] Lambda functions in list comprehensions Message-ID: <E19IXUz-0006AJ-00@sc8-sf-web3.sourceforge.net> Bugs item #734869, was opened at 2003-05-08 21:20 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734869&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Thomas Finley (tomfinley) Assigned to: Jeremy Hylton (jhylton) Summary: Lambda functions in list comprehensions Initial Comment: Lambda functions that return a list built through a list comprehension used in a list comprehension cause Python to die. Example: [ (lambda a:[a**i for i in range(a+1)])(j) for j in range(5) ] You can use "map" instead of list comprehension of course (as I illustrate in my example output), so this isn't a big deal, but I think it ought to work. What follows this paragraph is an interactive session in Python, where I illustrate the workings of my lambda function to illustrate that it does work correctly in several circumstances, but not in a list comprehension. I've done this with OS X Python 2.3b1, 2.2.2, 2.2, and Solaris Python 2.2a2 with the same results. ========= Python 2.3b1 (#1, May 6 2003, 01:40:43) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> (lambda a:[a**i for i in range(a+1)])(5) [1, 5, 25, 125, 625, 3125] >>> f = lambda a:[a**i for i in range(a+1)] >>> [ f(i) for i in range(5) ] [[1], [1, 1], [1, 2, 4], [1, 3, 9, 27], [1, 4, 16, 64, 256]] >>> map(lambda a:[a**i for i in range(a+1)], range(5)) [[1], [1, 1], [1, 2, 4], [1, 3, 9, 27], [1, 4, 16, 64, 256]] >>> [ (lambda a:[a**i for i in range(a+1)])(j) for j in range(5) ] Fatal Python error: unknown scope for _[1] in <lambda>(1) in <stdin> symbols: {'a': 12, '_[2]': 2, 'range': 8, 'i': 10} locals: {'a': 0, '_[2]': 1, 'i': 2} globals: {'range': True} Abort ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-21 17:35 Message: Logged In: YES user_id=31392 Fixed in rev. 2.285 of compile.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 23:43 Message: Logged In: YES user_id=80475 I can reproduce the error on Py2.1.3, Py2.2.2, and Py2.3b1. It should probably be fixed before Py2.2.3 goes out the door next week. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-09 11:19 Message: Logged In: YES user_id=6656 Argh. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734869&group_id=5470 From noreply@sourceforge.net Wed May 21 19:53:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 11:53:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support Message-ID: <E19IYiE-0008B0-00@sc8-sf-web4.sourceforge.net> Bugs item #741307, was opened at 2003-05-21 20:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Configure does NOT set properly *FLAGS for thread support Initial Comment: On Tru64Unix 5.1A(but also older version like Digital Unix 4.0 for example), there have to be specified CFLAGS="-pthread" and CXXFLAGS="-pthread", so that configure can detect working pthread.h. In case of Python-2.3b1 even when user set those both variables before running configure, at the link step gets: cc -o python \ Modules/ccpython.o \ libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm ld: Unresolved: __pthread_self __pthread_create __pthread_detach make: *** [python] Error 1 $ This can be easily fixed: $ cc -pthread -o python Modules/ccpython.o libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm $ I guess in this case LDFLAGS are in effect. So, configure should make sure -pthread is appended to all, CFLAGS, CXXFLAGS and LDFLAGS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 From noreply@sourceforge.net Wed May 21 19:58:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 11:58:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-741310 ] Cannot compile Python-2.3b1 on Tru64Unix 5.1A Message-ID: <E19IYnU-0008R1-00@sc8-sf-web4.sourceforge.net> Bugs item #741310, was opened at 2003-05-21 20: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=741310&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot compile Python-2.3b1 on Tru64Unix 5.1A Initial Comment: cc -DNDEBUG -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I. -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/./Include -I/software/alpha_dux51/usr/include -I/usr/local/include -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Include -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1 -c /afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Modules/tkappinit.c -o build/temp.osf1-V5.1-alpha-2.3/tkappinit.o cc: Error: /software/alpha_dux51/usr/include/tk.h, line 337: Ill-formed parameter type list. (parmtyplist) typedef int (Tk_OptionParseProc) _ANSI_ARGS_((ClientData clientData, ---------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 142: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_ConfigureWidget _ANSI_ARGS_((Tcl_Interp * interp, -------------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 237: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_DisplayName _ANSI_ARGS_((Tk_Window tkwin)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 327: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_GetAtomName _ANSI_ARGS_((Tk_Window tkwin, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 330: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_GetBinding _ANSI_ARGS_((Tcl_Interp * interp, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 410: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_GetScrollInfo _ANSI_ARGS_((Tcl_Interp * interp, -----------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 479: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOf3DBorder _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 482: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfAnchor _ANSI_ARGS_((Tk_Anchor anchor)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 484: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfBitmap _ANSI_ARGS_((Display * display, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 487: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfCapStyle _ANSI_ARGS_((int cap)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 489: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfColor _ANSI_ARGS_((XColor * colorPtr)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 491: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfCursor _ANSI_ARGS_((Display * display, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 494: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfFont _ANSI_ARGS_((Tk_Font font)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 496: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfImage _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 499: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfJoinStyle _ANSI_ARGS_((int join)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 501: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfJustify _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 504: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfRelief _ANSI_ARGS_((int relief)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 513: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_ParseArgv _ANSI_ARGS_((Tcl_Interp * interp, -------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 960: Ill-formed parameter type list. (parmtyplist) int (*tk_ConfigureWidget) _ANSI_ARGS_((Tcl_Interp * interp, Tk_Window tkwin, Tk_ConfigSpec * specs, int argc, CONST84 char ** argv, char * widgRec, int flags)); /* 29 */ ------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 986: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_DisplayName) _ANSI_ARGS_((Tk_Window tkwin)); /* 55 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1014: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_GetAtomName) _ANSI_ARGS_((Tk_Window tkwin, Atom atom)); /* 83 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1015: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_GetBinding) _ANSI_ARGS_((Tcl_Interp * interp, Tk_BindingTable bindingTable, ClientData object, CONST char * eventStr)); /* 84 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1039: Ill-formed parameter type list. (parmtyplist) int (*tk_GetScrollInfo) _ANSI_ARGS_((Tcl_Interp * interp, int argc, CONST84 char ** argv, double * dblPtr, int * intPtr)); /* 108 */ ----------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1061: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOf3DBorder) _ANSI_ARGS_((Tk_3DBorder border)); /* 130 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1062: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfAnchor) _ANSI_ARGS_((Tk_Anchor anchor)); /* 131 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1063: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfBitmap) _ANSI_ARGS_((Display * display, Pixmap bitmap)); /* 132 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1064: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfCapStyle) _ANSI_ARGS_((int cap)); /* 133 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1065: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfColor) _ANSI_ARGS_((XColor * colorPtr)); /* 134 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1066: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfCursor) _ANSI_ARGS_((Display * display, Tk_Cursor cursor)); /* 135 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1067: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfFont) _ANSI_ARGS_((Tk_Font font)); /* 136 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1068: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfImage) _ANSI_ARGS_((Tk_ImageMaster imageMaster)); /* 137 */ ----^ cc: Severe: More than 30 errors were encountered in the course of compilation. (toomanyerr) running build_scripts creating build/scripts-2.3 copying and adjusting /afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Tools/scripts/pydoc -> build/scripts-2.3 changing mode of build/scripts-2.3/pydoc from 644 to 755 $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741310&group_id=5470 From noreply@sourceforge.net Wed May 21 21:04:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 13:04:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-741029 ] HTMLParser -- possible bug in handle_comment Message-ID: <E19IZof-0003Uv-00@sc8-sf-web4.sourceforge.net> Bugs item #741029, was opened at 2003-05-21 05:35 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741029&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott Israel (scott_israel) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser -- possible bug in handle_comment Initial Comment: >>> import HTMLParser >>> class Parser(HTMLParser.HTMLParser): def __init__(self): HTMLParser.HTMLParser.__init__ (self) def handle_data(self,data): print 'DATA: %s' % data def handle_comment(self,comment): print 'COMMENT: %s' % comment >>> test3='<STYLE><!-- This is a comment --> </STYLE>' >>> p=Parser() >>> p.feed(test3) DATA: <!-- This is a comment --> Is this a bug? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=699438 No, <style> is one of the tags that uses CDATA to make comments irrelevant. This was done so to 'enable legacy support' by allowing authors to write: <style> <!-- body{dd:00;} --> </style> Without the comments, most legacy browsers would display the text "body{dd:00;}" on the rendered webpage. HTML Spec reference is here: http://www.w3.org/TR/html4/present/styles.html#h-14.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741029&group_id=5470 From noreply@sourceforge.net Wed May 21 22:08:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 14:08:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-740407 ] Can't browse methods and Classes Message-ID: <E19IapV-00084f-00@sc8-sf-web3.sourceforge.net> Bugs item #740407, was opened at 2003-05-20 12:19 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740407&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: hoka (hoka) >Assigned to: Mark Hammond (mhammond) Summary: Can't browse methods and Classes Initial Comment: If i want to show the method and classes under Browse Python Path i got every time this error: File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 123, in OnTreeItemExpanding self.AddSubList(itemHandle, self.GetSubList (item)) File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 137, in AddSubList self.AddItem(parentHandle, item) File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 140, in AddItem text = self.GetText(item) File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 266, in GetText return self.DelegateCall( item.GetText ) File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\hierlist.py", line 255, in DelegateCall return fn() File "D:\Python23\lib\site- packages\Pythonwin\pywin\tools\browseProjects.p y", line 26, in GetText return self.name + self.suffix TypeError: unsupported operand type(s) for +: 'instance' and 'str' win32ui: Exception in OnNotify() handler Greetings Kai ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-21 21:08 Message: Logged In: YES user_id=31392 I think this is a win32 bug, not a Python bug, right, Mark? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740407&group_id=5470 From noreply@sourceforge.net Wed May 21 22:10:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 14:10:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-738973 ] urllib2 CacheFTPHandler doesn't work on multiple dirs Message-ID: <E19IarE-00089W-00@sc8-sf-web3.sourceforge.net> Bugs item #738973, was opened at 2003-05-16 22:18 Message generated for change (Settings changed) made by jhylton 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" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738973&group_id=5470 From noreply@sourceforge.net Wed May 21 22:47:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 14:47:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-716168 ] Minor nested scopes doc issues Message-ID: <E19IbQZ-0008Jt-00@sc8-sf-web4.sourceforge.net> Bugs item #716168, was opened at 2003-04-06 10:09 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716168&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Jeremy Hylton (jhylton) Summary: Minor nested scopes doc issues Initial Comment: 1. In section "4.1 Naming and binding", in the list of binding operations, list comprehensions are missing. 2. Appendix "A. Future statements and nested scopes" doesn't contain the nested scopes docs (it's now section 4.1) but still says it does and that "it will be removed in Python 2.2" :-). ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-21 21:47 Message: Logged In: YES user_id=31392 Removed appendix A and move everything to the mainline. The ref manual says that the target of a for loop is a binding construct. A list comp is just one kind of statement that uses a for loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716168&group_id=5470 From noreply@sourceforge.net Wed May 21 23:29:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 15:29:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-741310 ] Cannot compile Python-2.3b1 on Tru64Unix 5.1A Message-ID: <E19Ic5J-00030x-00@sc8-sf-web3.sourceforge.net> Bugs item #741310, was opened at 2003-05-21 14:58 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741310&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot compile Python-2.3b1 on Tru64Unix 5.1A Initial Comment: cc -DNDEBUG -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I. -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/./Include -I/software/alpha_dux51/usr/include -I/usr/local/include -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Include -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1 -c /afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Modules/tkappinit.c -o build/temp.osf1-V5.1-alpha-2.3/tkappinit.o cc: Error: /software/alpha_dux51/usr/include/tk.h, line 337: Ill-formed parameter type list. (parmtyplist) typedef int (Tk_OptionParseProc) _ANSI_ARGS_((ClientData clientData, ---------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 142: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_ConfigureWidget _ANSI_ARGS_((Tcl_Interp * interp, -------------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 237: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_DisplayName _ANSI_ARGS_((Tk_Window tkwin)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 327: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_GetAtomName _ANSI_ARGS_((Tk_Window tkwin, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 330: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_GetBinding _ANSI_ARGS_((Tcl_Interp * interp, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 410: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_GetScrollInfo _ANSI_ARGS_((Tcl_Interp * interp, -----------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 479: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOf3DBorder _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 482: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfAnchor _ANSI_ARGS_((Tk_Anchor anchor)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 484: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfBitmap _ANSI_ARGS_((Display * display, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 487: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfCapStyle _ANSI_ARGS_((int cap)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 489: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfColor _ANSI_ARGS_((XColor * colorPtr)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 491: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfCursor _ANSI_ARGS_((Display * display, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 494: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfFont _ANSI_ARGS_((Tk_Font font)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 496: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfImage _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 499: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfJoinStyle _ANSI_ARGS_((int join)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 501: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfJustify _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 504: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfRelief _ANSI_ARGS_((int relief)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 513: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_ParseArgv _ANSI_ARGS_((Tcl_Interp * interp, -------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 960: Ill-formed parameter type list. (parmtyplist) int (*tk_ConfigureWidget) _ANSI_ARGS_((Tcl_Interp * interp, Tk_Window tkwin, Tk_ConfigSpec * specs, int argc, CONST84 char ** argv, char * widgRec, int flags)); /* 29 */ ------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 986: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_DisplayName) _ANSI_ARGS_((Tk_Window tkwin)); /* 55 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1014: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_GetAtomName) _ANSI_ARGS_((Tk_Window tkwin, Atom atom)); /* 83 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1015: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_GetBinding) _ANSI_ARGS_((Tcl_Interp * interp, Tk_BindingTable bindingTable, ClientData object, CONST char * eventStr)); /* 84 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1039: Ill-formed parameter type list. (parmtyplist) int (*tk_GetScrollInfo) _ANSI_ARGS_((Tcl_Interp * interp, int argc, CONST84 char ** argv, double * dblPtr, int * intPtr)); /* 108 */ ----------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1061: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOf3DBorder) _ANSI_ARGS_((Tk_3DBorder border)); /* 130 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1062: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfAnchor) _ANSI_ARGS_((Tk_Anchor anchor)); /* 131 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1063: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfBitmap) _ANSI_ARGS_((Display * display, Pixmap bitmap)); /* 132 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1064: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfCapStyle) _ANSI_ARGS_((int cap)); /* 133 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1065: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfColor) _ANSI_ARGS_((XColor * colorPtr)); /* 134 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1066: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfCursor) _ANSI_ARGS_((Display * display, Tk_Cursor cursor)); /* 135 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1067: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfFont) _ANSI_ARGS_((Tk_Font font)); /* 136 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1068: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfImage) _ANSI_ARGS_((Tk_ImageMaster imageMaster)); /* 137 */ ----^ cc: Severe: More than 30 errors were encountered in the course of compilation. (toomanyerr) running build_scripts creating build/scripts-2.3 copying and adjusting /afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Tools/scripts/pydoc -> build/scripts-2.3 changing mode of build/scripts-2.3/pydoc from 644 to 755 $ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 18:29 Message: Logged In: YES user_id=33168 The problem looks to be in tcl/tk. I am able to build on Tru64 5.1 using cc, so I can't diagnose your problem. Can you look into what is causing the problem in tcl/tk. _ANSI_ARGS_ should be defined in tcl.h which should be included. Is this getting a bad value? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741310&group_id=5470 From noreply@sourceforge.net Wed May 21 23:34:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 15:34:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current Message-ID: <E19Ic9v-0003VR-00@sc8-sf-web2.sourceforge.net> Bugs item #740234, was opened at 2003-05-19 23:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Till Plewe (tpx) Assigned to: Nobody/Anonymous (nobody) Summary: test/build-failures on FreeBSD stable/current Initial Comment: Using snapshot: python_2003-05-19_230000.tar.gz STABLE (FreeBSD 4.8-STABLE #14: Mon Apr 7) CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue May 20) BUILDFAILURE curses does not build; neither on CURRENT nor on STABLE (compiler complaint: /usr/include/ncurses.h:289: conflicting types for `wchar_t' /usr/include/stdlib.h:57: previous declaration of `wchar_t' /usr/include/ncurses.h:292: conflicting types for `wint_t' /usr/include/wchar.h:96: previous declaration of `wint_t' if lines /usr/include/ncurses.h:288-293 #ifndef __wchar_t typedef unsigned long wchar_t; #endif /* __wchar_t */ #ifndef __wint_t typedef long int wint_t; #endif /* __wint_t */ are deleted then curses builds) TESTFAILURES test_re fails on both CURRENT and STABLE test_long test_pow and many more (probably related) tests fail on current See attached file for details ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 18:34 Message: Logged In: YES user_id=33168 I think many of the failures are due to the test_long failure. If that problem is fixed, my guess is several other tests will start working. What compiler are you using? Can you try to debug the test_long failure? I don't think any python developers have access to a freebsd box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 From noreply@sourceforge.net Wed May 21 23:37:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 15:37:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-739909 ] IMAP4_SSL broken Message-ID: <E19IcDK-00081u-00@sc8-sf-web1.sourceforge.net> Bugs item #739909, was opened at 2003-05-19 11:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739909&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: IMAP4_SSL broken Initial Comment: Python 2.3b1 (#1, May 6 2003, 10:52:33) [GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import imaplib >>> imaplib.IMAP4_SSL('mailserver') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.3/imaplib.py", line 1071, in __init__ IMAP4.__init__(self, host, port) File "/usr/lib/python2.3/imaplib.py", line 156, in __init__ self.open(host, port) File "/usr/lib/python2.3/imaplib.py", line 1084, in open self.sslobj = socket.ssl(self.sock, self.keyfile, self.certfile) TypeError: ssl() argument 1 must be _socket.socket, not _socketobject ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 18:37 Message: Logged In: YES user_id=33168 Raising priority, there may be other problems similar to this. Not sure who should look at this though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739909&group_id=5470 From noreply@sourceforge.net Thu May 22 00:35:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 16:35:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: <E19Id6x-0003hF-00@sc8-sf-web4.sourceforge.net> Bugs item #728330, was opened at 2003-04-27 05:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 19:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 13:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 14:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 08:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Thu May 22 00:49:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 16:49:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-729236 ] building readline module fails on Irix 6.5 Message-ID: <E19IdKW-00023P-00@sc8-sf-web1.sourceforge.net> Bugs item #729236, was opened at 2003-04-28 19:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: alexandre gillet (gillet) Assigned to: Nobody/Anonymous (nobody) Summary: building readline module fails on Irix 6.5 Initial Comment: I am trying to build Python2.3b1 on a sgi Irix 6.5 using MIPSpro Compilers: Version 7.30 I can't get the readline module to build. I get the following error: cc -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include -I/mgl/prog/share/include/ -c ../Modules/readline.c -o Modules/readline.o cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587 The "return" expression type differs from the function return type. return completion_matches(text, *on_completion); ^ cc-1552 cc: WARNING File = ../Modules/readline.c, Line = 732 The variable "m" is set but never used. PyObject *m; ^ 1 error detected in the compilation of "../Modules/readline.c". gmake: *** [Modules/readline.o] Error 2 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 19:49 Message: Logged In: YES user_id=33168 Is HAVE_RL_COMPLETION_MATCHES defined? If so is rl_completion_matches() defined to return char ** in readline.h? If HAVE_* is not defined, where is completion_matches() defined and what does it return? ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 14:02 Message: Logged In: YES user_id=150999 I was able to compile readline on Irix after changing the function flex_complete. the function prototyte say it should return a char** .So we did put the following change and it works. Is it a right way to do it? ** readline.c 2003-05-09 13:45:38.000000000 -0700 --- readline.c~ 2003-03-01 07:19:41.000000000 -0800 *************** *** 577,589 **** /* A more flexible constructor that saves the "begidx" and "endidx" * before calling the normal completer */ ! static char ** flex_complete(char *text, int start, int end) { Py_XDECREF(begidx); Py_XDECREF(endidx); begidx = PyInt_FromLong((long) start); endidx = PyInt_FromLong((long) end); ! return (char **)completion_matches(text, *on_completion); } --- 577,590 ---- /* A more flexible constructor that saves the "begidx" and "endidx" * before calling the normal completer */ ! static char ** ! flex_complete(char *text, int start, int end) { Py_XDECREF(begidx); Py_XDECREF(endidx); begidx = PyInt_FromLong((long) start); endidx = PyInt_FromLong((long) end); ! return completion_matches(text, *on_completion); } ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 13:44 Message: Logged In: YES user_id=150999 My readline version is 4.3 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-29 07:44 Message: Logged In: YES user_id=21627 What is your readline version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470 From noreply@sourceforge.net Thu May 22 01:41:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 17:41:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball Message-ID: <E19Ie9F-0005Zx-00@sc8-sf-web4.sourceforge.net> Bugs item #728051, was opened at 2003-04-27 00:23 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Neal Norwitz (nnorwitz) Summary: Test failures on Linux, Python 2.3b1 tarball Initial Comment: "make test" resulted in: test test_tempfile failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test test_time failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/Python-2.3b1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-05-22 10:41 Message: Logged In: YES user_id=46639 This is from my patch. Phillip - can you please upload a copy of 'man tzset' on that Redhat box or email it to zen@shangri-la.dropbear.id.au. I'd also like to see the output of: python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='US/Eastern' \ python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='Australia/Melbourne' \ python -c 'import time;print time.tzname,time.timezone,time.altzone' I'm thinking that tzset(3) and the time libraries are not fully functional on this earlier version of Redhat, possibly by not handling southern hemisphere daylight savings. If so, it needs to be detected during configuration. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 01:00 Message: Logged In: YES user_id=21627 Neal, it appears you have checked in the test for the AEST zone. Can you analyse the test_time failure in more detail? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-04 23:19 Message: Logged In: YES user_id=56214 It's an ISP-supplied variant of RedHat 6.2. I see 'libc-2.1.3.so' in the /lib directory, so I assume that's the version. Running 'strings' on it, I find: GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Python identifies itself as: Python 2.3b1 (#1, Apr 26 2003, 10:02:40) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 I just tested 2.3a1 andr 2.3a2 to confirm where the errors began. 2.3a1 doesn't show either error. 2.3a2 has the tempfile problem, but not the time problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 22:42 Message: Logged In: YES user_id=21627 What operating system distribution specifically did you use? What C library does this system use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 From noreply@sourceforge.net Thu May 22 02:28:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 18:28:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-628925 ] pickle won't dump instances after reload Message-ID: <E19IesF-0000N4-00@sc8-sf-web3.sourceforge.net> Bugs item #628925, was opened at 2002-10-25 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628925&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dave Cole (davecole) Assigned to: Nobody/Anonymous (nobody) Summary: pickle won't dump instances after reload Initial Comment: The fix for bug http://python.org/sf/451547 has made the follow sequence fail: >>> import pickle, copy >>> o = copy._EmptyClass() >>> reload(copy) <module 'copy' from '/usr/lib/python2.2/copy.pyc'> >>> pickle.dumps(o, 1) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/pickle.py", line 978, in dumps Pickler(file, bin).dump(object) File "/usr/lib/python2.2/pickle.py", line 115, in dump self.save(object) File "/usr/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/lib/python2.2/pickle.py", line 477, in save_inst save(cls) File "/usr/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/lib/python2.2/pickle.py", line 524, in save_global raise PicklingError( pickle.PicklingError: Can't pickle <class copy._EmptyClass at 0x819478c>: it's not the same object as copy._EmptyClass Looking at bug 451547 the reported problem was that pickle would allow you to dump lambdas. When you try to dump lambdas you now see the following: >>> f = lambda x: x in (1,2,3) >>> s = pickle.dumps(f, 1) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/pickle.py", line 978, in dumps Pickler(file, bin).dump(object) File "/usr/lib/python2.2/pickle.py", line 115, in dump self.save(object) File "/usr/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/lib/python2.2/pickle.py", line 519, in save_global raise PicklingError( pickle.PicklingError: Can't pickle <function <lambda> at 0x8157edc>: it's not found as __main__.<lambda> The reported lambda problem is found without having to check that the manually resolved class object is at the same memory address as the class object referenced by the lambda. I think the pickle code is being too careful. >From pickle.py: the "klass is not object" test in the else clause should probably be removed. try: __import__(module) mod = sys.modules[module] klass = getattr(mod, name) except (ImportError, KeyError, AttributeError): raise PicklingError( "Can't pickle %r: it's not found as %s.%s" % (object, module, name)) else: if klass is not object: raise PicklingError( "Can't pickle %r: it's not the same object as %s.%s" % (object, module, name)) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-21 18:28 Message: Logged In: YES user_id=357491 It's still there for 2.3b1. It seems to pickle without raising an error when it uses the text format. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628925&group_id=5470 From noreply@sourceforge.net Thu May 22 03:20:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 19:20:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-635814 ] cStringIO().write TypeError Message-ID: <E19IfhA-0000MX-00@sc8-sf-web4.sourceforge.net> Bugs item #635814, was opened at 2002-11-08 18:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: kris kvilekval (kgk) Assigned to: M.-A. Lemburg (lemburg) Summary: cStringIO().write TypeError Initial Comment: There is an incompatibilty between StringIO and cStringIO, as demonstrated below.. Passing an integer to StringIO.write is OK while it not OK to pass one to cStringIO. $ python Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO >>> sfile = StringIO.StringIO() >>> sfile.write (100) >>> print sfile.getvalue() 100 >>> import cStringIO >>> cfile = cStringIO.StringIO() >>> cfile.write (100) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: write() argument 1 must be string or read-only buffer, not int >>> cfile.write (str(100)) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-21 19:20 Message: Logged In: YES user_id=357491 If this bug cannot be fixed then shouldn't this bug report be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 13:35 Message: Logged In: YES user_id=21627 It's a bug that StringIO accepts it. file.write does not support numbers, either. Unfortunately, this bug cannot be fixed, for backwards compatibility. The conversion of any argument to a string was originally introduced for Python 2.2, to support arbitrary buffer objects. That it also accepts numbers now was an unexpected side effect. Assigning to Marc-Andre, as he introduced that feature originally. ---------------------------------------------------------------------- Comment By: kris kvilekval (kgk) Date: 2002-11-09 13:09 Message: Logged In: YES user_id=569286 This seems like an unnecessary incompatibility, however I guess it is there in the interest of speed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 10:04 Message: Logged In: YES user_id=21627 This is by design. The file protocol makes no guarantee that you can write objects other than strings into a file, unless the object explicitly documents the support for other objects. cStringIO differs in many ways from StringIO, this is but one way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 From noreply@sourceforge.net Thu May 22 04:14:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 20:14:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-639311 ] urllib.basejoin() mishandles '' Message-ID: <E19IgXK-0001hc-00@sc8-sf-web4.sourceforge.net> Bugs item #639311, was opened at 2002-11-16 04:34 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.basejoin() mishandles '' Initial Comment: It's not entirely clear whether urllib.basejoin() intends to implement RFC 2396's "resolution of relative URI references to absolute form" faithfully, but it seems to behave improperly when given an empty string as the relative URI to make absolute. >>> from urllib import basejoin >>> basejoin('http://host/foo/bar.xml','') 'http://host/foo/' I believe it should return the base as-is, because the empty string is a reference to the document that contains that reference... and presumably the document's URI is what you're passing in as the base. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-21 20:14 Message: Logged In: YES user_id=357491 Perhaps urllib.basejoin (which is not documented) should just become a wrapper for urlparse.urljoin ? It won't solve this bug but it would cut back on unneeded code. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-11-26 02:41 Message: Logged In: YES user_id=371366 I was partly mistaken; the document's URI is not necessarily the base. A reference with an empty path (e.g., an empty string or just a fragment identifier) is a reference to the current document, regardless of the base URI you are resolving against. A base URI is only for resolving relative URIs that are not referencing the current document. See some discussion at http://lists.w3.org/Archives/Public/uri/2002Jan/0015.html So neither urllib.basejoin() nor urlparse.urljoin() fully implement the RFC 2396 "resolution to absolute form", since there would need to be a way to indicate "current document" other than returning the base. Nevertheless, basejoin()'s behavior differs from urlparse.urljoin ()'s when presented with the empty string, and it's not clear whether that is intentional. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470 From noreply@sourceforge.net Thu May 22 04:32:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 20:32:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-730222 ] socketmodule.c: inet_pton() expects 4-byte packed_addr Message-ID: <E19Igob-00049y-00@sc8-sf-web2.sourceforge.net> Bugs item #730222, was opened at 2003-04-30 11:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: John Marshall (john_marshall) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: inet_pton() expects 4-byte packed_addr Initial Comment: In the Modules/socketmodule.c file, the inet_pton function implicitly treats "long packed_addr" as a 4-byte object or expects that the required 4-bytes is at &packed_addr[0]-[3]. This is not true under SUPER-UX/SX. In order to get this working right, I changed the data type from "long" to "int". This now works properly. -----Modules/socketmodule.c: #3825 /* 042303; JM; this routine really expects a 4-byte packed_addr * not a long; long on SX is 8-bytes! */ #if SX int packed_addr; #else long packed_addr; #endif ... if (packed_addr == INADDR_NONE) return 0; memcpy(dst, &packed_addr, 4); ----- ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:32 Message: Logged In: YES user_id=33168 Attached is a patch which should fix the problem. There was one other place that needed to be changed. This change is more generic. Let me know if it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 From noreply@sourceforge.net Thu May 22 04:34:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 20:34:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support Message-ID: <E19IgqM-0004BZ-00@sc8-sf-web2.sourceforge.net> Bugs item #741307, was opened at 2003-05-21 14:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Configure does NOT set properly *FLAGS for thread support Initial Comment: On Tru64Unix 5.1A(but also older version like Digital Unix 4.0 for example), there have to be specified CFLAGS="-pthread" and CXXFLAGS="-pthread", so that configure can detect working pthread.h. In case of Python-2.3b1 even when user set those both variables before running configure, at the link step gets: cc -o python \ Modules/ccpython.o \ libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm ld: Unresolved: __pthread_self __pthread_create __pthread_detach make: *** [python] Error 1 $ This can be easily fixed: $ cc -pthread -o python Modules/ccpython.o libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm $ I guess in this case LDFLAGS are in effect. So, configure should make sure -pthread is appended to all, CFLAGS, CXXFLAGS and LDFLAGS. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:34 Message: Logged In: YES user_id=33168 Is this only with the Dec/Compaq/HP compiler (cc/cxx)? Do you know if python links ok with gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 From noreply@sourceforge.net Thu May 22 05:05:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 21:05:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-644345 ] Poor error message for augmented assign Message-ID: <E19IhKF-00058R-00@sc8-sf-web2.sourceforge.net> Bugs item #644345, was opened at 2002-11-26 13:22 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644345&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Jeremy Hylton (jhylton) Summary: Poor error message for augmented assign Initial Comment: >>> [1,2] += [2,3] SyntaxError: augmented assign to list not possible A similar error message is generated when augmented assignment is used on tuple literals. This error message is desceptive because augmented assignment is allowed on both of those types. I would change the message to: SyntaxError: can't assign to literal I may generate a patch for this, but not anytime soon. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-21 21:05 Message: Logged In: YES user_id=357491 I like Neal's suggestion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 05:16 Message: Logged In: YES user_id=33168 Jeremy, do you agree? How about adding the word literal to the error msg, so it reads: * augmented assign to literal list not possible ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644345&group_id=5470 From noreply@sourceforge.net Thu May 22 05:09:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 21:09:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-645594 ] for lin in file: file.tell() tells wrong Message-ID: <E19IhO0-000521-00@sc8-sf-web3.sourceforge.net> Bugs item #645594, was opened at 2002-11-29 01:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 >Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: for lin in file: file.tell() tells wrong Initial Comment: Consider following piece of code: f = file("test.txt", "rb") pos = f.tell() for line in f: print "%u: '%s'" % (pos, line) pos = f.tell() During the code execution we have following result: 0 'Line 1' 63 'Line 2' 63 'Line 3' ... 63 'Line 9' However, following piece of code works fine: f = file("test.txt", "rb") while True: pos = f.tell() line = f.readline() if line == "": break print "%u: '%s'" % (pos, line) It prints: 0 'Line 1' 7 'Line 2' 14 'Line 3' ... 56 'Line 9' It seems a file iterator makes file.tell() to tell positions of some internal blocks used by the iterator. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-21 21:09 Message: Logged In: YES user_id=357491 As suggested by Just and Dimtry I am reclassifying this as a doc bug. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-01-08 02:17 Message: Logged In: YES user_id=388573 I agree. Unfortunately a small patch doesn't work here. :-( But I suggest to recategorize it as a documentation bug. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 13:25 Message: Logged In: YES user_id=92689 This bug is very similar to #524804, which was closed as "won't fix". Unless it's recategorized as a documentation bug, I suggest to close this one as a duplicate. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-12-04 03:24 Message: Logged In: YES user_id=388573 File.next() uses readahead buffer (8192 bytes for now). Calling file.seek() drops the buffer, but other operations don't. I think it's possible for file.tell() to return right result (I'll try to make a patch). But all these quirks should be documented. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-29 14:07 Message: Logged In: YES user_id=45365 Actually, all file operations behave the same (well, all: I tried one: readline():-): they behave as if the whole file has been read. I.e. file.readline() within a "for line in file" will return an empty string. If a file iterator behaves as if it has read the complete file at once on instantiation (never mind what it actually does: if it *behaves* as if this happens) I think this should just be documented and that's it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 08:57 Message: Logged In: YES user_id=31435 Possibly. Maybe something fancier could be done too, to give "expected" results. although I don't know how to approach that on Windows for text-mode files (byte arithmetic on seek/tell results doesn't work at all for those). I'd take it to Python-Dev. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-29 08:01 Message: Logged In: YES user_id=21627 Shouldn't tell raise an exception then? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 07:42 Message: Logged In: YES user_id=31435 "for x in file" does do its own chunking under the covers, for speed, and seek() and tell() are indeed not to be used on a file being iterated over in this way. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-11-29 06:46 Message: Logged In: YES user_id=388573 I'll try to dig in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-29 06:30 Message: Logged In: YES user_id=21627 Would you like to investigate this further? There is no need to, but if you find a solution and a patch, there is a better chance that this is fixed before 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 From noreply@sourceforge.net Thu May 22 05:57:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 21:57:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current Message-ID: <E19Ii9I-0004Xo-00@sc8-sf-web4.sourceforge.net> Bugs item #740234, was opened at 2003-05-20 03:50 Message generated for change (Comment added) made by tpx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Till Plewe (tpx) Assigned to: Nobody/Anonymous (nobody) Summary: test/build-failures on FreeBSD stable/current Initial Comment: Using snapshot: python_2003-05-19_230000.tar.gz STABLE (FreeBSD 4.8-STABLE #14: Mon Apr 7) CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue May 20) BUILDFAILURE curses does not build; neither on CURRENT nor on STABLE (compiler complaint: /usr/include/ncurses.h:289: conflicting types for `wchar_t' /usr/include/stdlib.h:57: previous declaration of `wchar_t' /usr/include/ncurses.h:292: conflicting types for `wint_t' /usr/include/wchar.h:96: previous declaration of `wint_t' if lines /usr/include/ncurses.h:288-293 #ifndef __wchar_t typedef unsigned long wchar_t; #endif /* __wchar_t */ #ifndef __wint_t typedef long int wint_t; #endif /* __wint_t */ are deleted then curses builds) TESTFAILURES test_re fails on both CURRENT and STABLE test_long test_pow and many more (probably related) tests fail on current See attached file for details ---------------------------------------------------------------------- >Comment By: Till Plewe (tpx) Date: 2003-05-22 04:57 Message: Logged In: YES user_id=782552 I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release). Most of the test failures seem to be gcc-bugs. Rebuilding world with the extra compiler flag -mno-sse2 got rid of most test failures. Now only the test_re failure and the curses build failure remain. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 22:34 Message: Logged In: YES user_id=33168 I think many of the failures are due to the test_long failure. If that problem is fixed, my guess is several other tests will start working. What compiler are you using? Can you try to debug the test_long failure? I don't think any python developers have access to a freebsd box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 From noreply@sourceforge.net Thu May 22 06:04:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 22:04:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current Message-ID: <E19IiFV-0002St-00@sc8-sf-web1.sourceforge.net> Bugs item #740234, was opened at 2003-05-20 03:50 Message generated for change (Comment added) made by tpx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Till Plewe (tpx) Assigned to: Nobody/Anonymous (nobody) Summary: test/build-failures on FreeBSD stable/current Initial Comment: Using snapshot: python_2003-05-19_230000.tar.gz STABLE (FreeBSD 4.8-STABLE #14: Mon Apr 7) CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue May 20) BUILDFAILURE curses does not build; neither on CURRENT nor on STABLE (compiler complaint: /usr/include/ncurses.h:289: conflicting types for `wchar_t' /usr/include/stdlib.h:57: previous declaration of `wchar_t' /usr/include/ncurses.h:292: conflicting types for `wint_t' /usr/include/wchar.h:96: previous declaration of `wint_t' if lines /usr/include/ncurses.h:288-293 #ifndef __wchar_t typedef unsigned long wchar_t; #endif /* __wchar_t */ #ifndef __wint_t typedef long int wint_t; #endif /* __wint_t */ are deleted then curses builds) TESTFAILURES test_re fails on both CURRENT and STABLE test_long test_pow and many more (probably related) tests fail on current See attached file for details ---------------------------------------------------------------------- >Comment By: Till Plewe (tpx) Date: 2003-05-22 05:04 Message: Logged In: YES user_id=782552 Most of the test failures on FreeBSD CURRENT seem to be gcc bugs. (I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release)) Rebuilding world with the additional compiler flag -mno-sse2 got rid of most test failures. Now only the curses build failure and the test_re failure remain. ---------------------------------------------------------------------- Comment By: Till Plewe (tpx) Date: 2003-05-22 04:57 Message: Logged In: YES user_id=782552 I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release). Most of the test failures seem to be gcc-bugs. Rebuilding world with the extra compiler flag -mno-sse2 got rid of most test failures. Now only the test_re failure and the curses build failure remain. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 22:34 Message: Logged In: YES user_id=33168 I think many of the failures are due to the test_long failure. If that problem is fixed, my guess is several other tests will start working. What compiler are you using? Can you try to debug the test_long failure? I don't think any python developers have access to a freebsd box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 From noreply@sourceforge.net Thu May 22 07:47:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 23:47:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: <E19Ijqz-0005tm-00@sc8-sf-web1.sourceforge.net> Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-22 08:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 01:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 19:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 20:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Thu May 22 07:49:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 21 May 2003 23:49:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-635814 ] cStringIO().write TypeError Message-ID: <E19Ijt7-00060V-00@sc8-sf-web1.sourceforge.net> Bugs item #635814, was opened at 2002-11-09 03:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: kris kvilekval (kgk) Assigned to: M.-A. Lemburg (lemburg) Summary: cStringIO().write TypeError Initial Comment: There is an incompatibilty between StringIO and cStringIO, as demonstrated below.. Passing an integer to StringIO.write is OK while it not OK to pass one to cStringIO. $ python Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO >>> sfile = StringIO.StringIO() >>> sfile.write (100) >>> print sfile.getvalue() 100 >>> import cStringIO >>> cfile = cStringIO.StringIO() >>> cfile.write (100) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: write() argument 1 must be string or read-only buffer, not int >>> cfile.write (str(100)) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-22 08:49 Message: Logged In: YES user_id=21627 Indeed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-22 04:20 Message: Logged In: YES user_id=357491 If this bug cannot be fixed then shouldn't this bug report be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 22:35 Message: Logged In: YES user_id=21627 It's a bug that StringIO accepts it. file.write does not support numbers, either. Unfortunately, this bug cannot be fixed, for backwards compatibility. The conversion of any argument to a string was originally introduced for Python 2.2, to support arbitrary buffer objects. That it also accepts numbers now was an unexpected side effect. Assigning to Marc-Andre, as he introduced that feature originally. ---------------------------------------------------------------------- Comment By: kris kvilekval (kgk) Date: 2002-11-09 22:09 Message: Logged In: YES user_id=569286 This seems like an unnecessary incompatibility, however I guess it is there in the interest of speed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:04 Message: Logged In: YES user_id=21627 This is by design. The file protocol makes no guarantee that you can write objects other than strings into a file, unless the object explicitly documents the support for other objects. cStringIO differs in many ways from StringIO, this is but one way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 From noreply@sourceforge.net Thu May 22 08:24:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 00:24:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support Message-ID: <E19IkRf-0007S5-00@sc8-sf-web1.sourceforge.net> Bugs item #741307, was opened at 2003-05-21 20:53 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Configure does NOT set properly *FLAGS for thread support Initial Comment: On Tru64Unix 5.1A(but also older version like Digital Unix 4.0 for example), there have to be specified CFLAGS="-pthread" and CXXFLAGS="-pthread", so that configure can detect working pthread.h. In case of Python-2.3b1 even when user set those both variables before running configure, at the link step gets: cc -o python \ Modules/ccpython.o \ libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm ld: Unresolved: __pthread_self __pthread_create __pthread_detach make: *** [python] Error 1 $ This can be easily fixed: $ cc -pthread -o python Modules/ccpython.o libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm $ I guess in this case LDFLAGS are in effect. So, configure should make sure -pthread is appended to all, CFLAGS, CXXFLAGS and LDFLAGS. ---------------------------------------------------------------------- >Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 09:24 Message: Logged In: YES user_id=696559 This is specific for Dec/Compaq/HP compiler. The manpage for cc says: -pthread Directs the linker to use the threadsafe version of any library speci- fied with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.1c-conformant DECthreads inter- faces in libpthread when linking the program. This option also defines the _REENTRANT macro. As I remeber from experience, it's not enough to use it really as LDFLAG supplied to ld. The code has to be compiled with that flag already and therefore I set CC or CFLAGS to contain this value. Same applies for CXX or CXXFLAGS. Actually, there's a configure macro check, I saw it somewhere in documentation on the web. I posted that once into some my bugreport in GNOME bugzilla. You can dig out from there that URL. Unfortunately, bugzilla searches never worked for me. :( As for gcc: $ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure [...] checking whether pthreads are available without options... no checking whether gcc accepts -Kpthread... no [...] checking for --with-dec-threads... no checking for --with-threads... yes checking for _POSIX_THREADS in unistd.h... yes checking cthreads.h usability... no checking cthreads.h presence... no checking for cthreads.h... no checking mach/cthreads.h usability... no checking mach/cthreads.h presence... no checking for mach/cthreads.h... no checking for --with-pth... no checking for pthread_create in -lpthread... yes checking if PTHREAD_SCOPE_SYSTEM is supported... yes checking for pthread_sigmask... yes from config.log: configure:3753: checking whether pthreads are available without options configure:3779: gcc -o conftest -O2 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c -L/usr/l ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 In file included from configure:3763: /usr/include/pthread.h:312:4: #error "Please compile the module including pthread.h with -pthread" configure:3782: $? = 1 configure: program exited with status 1 configure: failed program was: #line 3761 "configure" #include "confdefs.h" #include <pthread.h> void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } configure:3802: result: no So, to conclude, -pthread has to be specified even for gcc/g++. Simply, always on ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 05:34 Message: Logged In: YES user_id=33168 Is this only with the Dec/Compaq/HP compiler (cc/cxx)? Do you know if python links ok with gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 From noreply@sourceforge.net Thu May 22 08:44:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 00:44:43 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-721061 ] Add copyrange method to array. Message-ID: <E19Ikkl-0003fZ-00@sc8-sf-web2.sourceforge.net> Feature Requests item #721061, was opened at 2003-04-14 07:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=721061&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add copyrange method to array. Initial Comment: The split buffer data structure commonly used in text editors to efficiently manipulate text and data attached to that text can be implemented using the Python array type with the addition of a way to rapidly copy data within arrays. There may be other situations in which rapidly copying blocks within an array is useful. -- Neil Hodgson ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 02:44 Message: Logged In: YES user_id=80475 Moving to feature requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=721061&group_id=5470 From noreply@sourceforge.net Thu May 22 08:48:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 00:48:21 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-721061 ] Add copyrange method to array. Message-ID: <E19IkoH-0003nF-00@sc8-sf-web2.sourceforge.net> Feature Requests item #721061, was opened at 2003-04-14 07:41 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=721061&group_id=5470 >Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Add copyrange method to array. Initial Comment: The split buffer data structure commonly used in text editors to efficiently manipulate text and data attached to that text can be implemented using the Python array type with the addition of a way to rapidly copy data within arrays. There may be other situations in which rapidly copying blocks within an array is useful. -- Neil Hodgson ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 02:44 Message: Logged In: YES user_id=80475 Moving to feature requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=721061&group_id=5470 From noreply@sourceforge.net Thu May 22 08:53:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 00:53:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-685773 ] 2 (more) bugs in turtle Message-ID: <E19Ikt8-00043l-00@sc8-sf-web2.sourceforge.net> Bugs item #685773, was opened at 2003-02-13 02:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685773&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Smith (smichr) >Assigned to: Raymond Hettinger (rhettinger) Summary: 2 (more) bugs in turtle Initial Comment: 1) After initiating filling with the fill(1) command, the next fill command (e.g. fill(0)) does not cause the filling to take place. FIlling does not occur until the next draw statement occurs. SOLUTION: ### At the end of the IF block in fill(), put the following lines as delimited below with the #-- comment: def fill(self, flag): if self._filling: <cut> self._items.append(item) #--cps Addition to force filling. Filling doesn't occur until #--a move command is issued, so a "move" to the #--present position is being issued to force the #--filling to occur. x,y=self._position self._goto(x,y) #-- self._path = [] ### 2) The last line of the goto() (not the _goto()) function incorrectly computes the x coordinate as x-x0. You can verify this by issuing a goto(0,0) command as the first turtle command: the turtle wanders off of the origin. SOLUTION The coordinate should be computed as x0+x as shown below (again, this is the last line of the goto() function): self._goto(x0+x, y0-y) /c ---------------------------------------------------------------------- Comment By: Christopher Smith (smichr) Date: 2003-03-01 18:27 Message: Logged In: YES user_id=514525 Regarding #2, I don't know what I was looking at! :-( I am looking again at the code and it is x0+x, y0-y as it should be. Disregard #2. /c ---------------------------------------------------------------------- Comment By: Christopher Smith (smichr) Date: 2003-02-26 03:21 Message: Logged In: YES user_id=514525 Regarding #1, a better patch has been to name the fill() function as _fill() and create a new fill() function as follows: def fill(self,n): self._fill(n) self.forward(0) #a null move The previous patch from #1 (as I learned) did not fill circles properly. /c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685773&group_id=5470 From noreply@sourceforge.net Thu May 22 08:57:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 00:57:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-683486 ] Tutorial: info on Source Code Encoding is missing Message-ID: <E19IkxN-0004Fx-00@sc8-sf-web2.sourceforge.net> Bugs item #683486, was opened at 2003-02-09 12:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683486&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roman Suzi (rnd0110) >Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial: info on Source Code Encoding is missing Initial Comment: (I propose to add information into Tutorial on how to specify source code encoding. Please correct my English and maybe there is better way to get a list of possible encodings) 2.2.2 Executable Python Scripts ... 2.2.3 Source Code Encoding It is possible to use encodings different than ASCII in Python source files. The best way to do it is to put one more special comment line right after #!-line making proper encoding declaration: # -*- coding: latin-1 -*- After that, all characters in the source file will be treated as belonging to latin-1 encoding, and it will be possible to directly write Unicode strings in the selected encoding. List of possible encodings could be found in the encodings subdirectory of Python directory. Significant advantage could be had if using utf-8 encoding, as it allows to use letters from many languages in the same file. 2.2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683486&group_id=5470 From noreply@sourceforge.net Thu May 22 08:59:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 00:59:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-687648 ] classic division in demos/ directory Message-ID: <E19Ikz5-0004KI-00@sc8-sf-web2.sourceforge.net> Bugs item #687648, was opened at 2003-02-16 17:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687648&group_id=5470 Category: Demos and Tools Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: classic division in demos/ directory Initial Comment: PEP 238 states: - The standard library will use the future division statement and the // operator when appropriate, so as to completely avoid classic division. While the demos/ directory is not technically part of the standard library, it does contain code that should work, and that newbies may examine in the course of learning Python. Python source there should follow the same rules as anyplace else. I'll volunteer to make the changes and submit a patch, if it is agreed that the changes should indeed be made. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 02:59 Message: Logged In: YES user_id=80475 Is this still open or is there a patch forthcoming? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 08:48 Message: Logged In: YES user_id=6380 Excellent. I hope you'll try to also make a judgement (at least in some cases) whether a particular piece of demo code is still relevant -- there is unfortunately a lot of stale demo code. Also see if there are other kinds of modernization that could be done (see PEP 290). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687648&group_id=5470 From noreply@sourceforge.net Thu May 22 09:04:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 01:04:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-660022 ] parameters for int(), str(), etc. Message-ID: <E19Il3n-0004Uj-00@sc8-sf-web2.sourceforge.net> Bugs item #660022, was opened at 2002-12-30 10:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) >Assigned to: Raymond Hettinger (rhettinger) Summary: parameters for int(), str(), etc. Initial Comment: The built-in functions int(), str(), float(), long() are documented as requiring a parameter, but the type/class unification has changed them so that they return a false object without a parameter: >>> int() 0 >>> str() '' >>> float() 0.0 >>> long() 0L ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-01 23:31 Message: Logged In: YES user_id=80475 There are a lot of these: [(0, False), (0.0, False), (0j, False), (0L, False), ((), False), ([], False), ({}, False), ('', False), (u'', False)] See attached doc patch. Also, consider adding a \versionchanged tag and changing the doc strings. BTW, I think it is more complete and accurate to say that the contructors return an empty container or zero than it is to just say that bool(constructor()) is False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470 From noreply@sourceforge.net Thu May 22 09:28:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 01:28:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support Message-ID: <E19IlQn-0005S2-00@sc8-sf-web2.sourceforge.net> Bugs item #741307, was opened at 2003-05-21 20:53 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Configure does NOT set properly *FLAGS for thread support Initial Comment: On Tru64Unix 5.1A(but also older version like Digital Unix 4.0 for example), there have to be specified CFLAGS="-pthread" and CXXFLAGS="-pthread", so that configure can detect working pthread.h. In case of Python-2.3b1 even when user set those both variables before running configure, at the link step gets: cc -o python \ Modules/ccpython.o \ libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm ld: Unresolved: __pthread_self __pthread_create __pthread_detach make: *** [python] Error 1 $ This can be easily fixed: $ cc -pthread -o python Modules/ccpython.o libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm $ I guess in this case LDFLAGS are in effect. So, configure should make sure -pthread is appended to all, CFLAGS, CXXFLAGS and LDFLAGS. ---------------------------------------------------------------------- >Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 10:28 Message: Logged In: YES user_id=696559 BTW: With gcc, I don't get even to the link step: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o Modules/posixmodule.c: In function `posix_stat': Modules/posixmodule.c:1851: `stat' undeclared (first use in this function) Modules/posixmodule.c:1851: (Each undeclared identifier is reported only once Modules/posixmodule.c:1851: for each function it appears in.) Modules/posixmodule.c: In function `posix_plock': Modules/posixmodule.c:2956: warning: implicit declaration of function `plock' Modules/posixmodule.c: In function `posix_lstat': Modules/posixmodule.c:4683: `lstat' undeclared (first use in this function) Modules/posixmodule.c: In function `posix_unsetenv': Modules/posixmodule.c:5431: warning: implicit declaration of function `unsetenv' make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 09:24 Message: Logged In: YES user_id=696559 This is specific for Dec/Compaq/HP compiler. The manpage for cc says: -pthread Directs the linker to use the threadsafe version of any library speci- fied with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.1c-conformant DECthreads inter- faces in libpthread when linking the program. This option also defines the _REENTRANT macro. As I remeber from experience, it's not enough to use it really as LDFLAG supplied to ld. The code has to be compiled with that flag already and therefore I set CC or CFLAGS to contain this value. Same applies for CXX or CXXFLAGS. Actually, there's a configure macro check, I saw it somewhere in documentation on the web. I posted that once into some my bugreport in GNOME bugzilla. You can dig out from there that URL. Unfortunately, bugzilla searches never worked for me. :( As for gcc: $ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure [...] checking whether pthreads are available without options... no checking whether gcc accepts -Kpthread... no [...] checking for --with-dec-threads... no checking for --with-threads... yes checking for _POSIX_THREADS in unistd.h... yes checking cthreads.h usability... no checking cthreads.h presence... no checking for cthreads.h... no checking mach/cthreads.h usability... no checking mach/cthreads.h presence... no checking for mach/cthreads.h... no checking for --with-pth... no checking for pthread_create in -lpthread... yes checking if PTHREAD_SCOPE_SYSTEM is supported... yes checking for pthread_sigmask... yes from config.log: configure:3753: checking whether pthreads are available without options configure:3779: gcc -o conftest -O2 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c -L/usr/l ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 In file included from configure:3763: /usr/include/pthread.h:312:4: #error "Please compile the module including pthread.h with -pthread" configure:3782: $? = 1 configure: program exited with status 1 configure: failed program was: #line 3761 "configure" #include "confdefs.h" #include <pthread.h> void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } configure:3802: result: no So, to conclude, -pthread has to be specified even for gcc/g++. Simply, always on ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 05:34 Message: Logged In: YES user_id=33168 Is this only with the Dec/Compaq/HP compiler (cc/cxx)? Do you know if python links ok with gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 From noreply@sourceforge.net Thu May 22 15:20:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 07:20:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support Message-ID: <E19Iqvw-0002iM-00@sc8-sf-web4.sourceforge.net> Bugs item #741307, was opened at 2003-05-21 20:53 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Configure does NOT set properly *FLAGS for thread support Initial Comment: On Tru64Unix 5.1A(but also older version like Digital Unix 4.0 for example), there have to be specified CFLAGS="-pthread" and CXXFLAGS="-pthread", so that configure can detect working pthread.h. In case of Python-2.3b1 even when user set those both variables before running configure, at the link step gets: cc -o python \ Modules/ccpython.o \ libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm ld: Unresolved: __pthread_self __pthread_create __pthread_detach make: *** [python] Error 1 $ This can be easily fixed: $ cc -pthread -o python Modules/ccpython.o libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm $ I guess in this case LDFLAGS are in effect. So, configure should make sure -pthread is appended to all, CFLAGS, CXXFLAGS and LDFLAGS. ---------------------------------------------------------------------- >Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 16:20 Message: Logged In: YES user_id=696559 So, this is a solution: CC="cc -pthread" CXX="cxx -pthread" CFLAGS="$CFLAGS -pthread" CXXFLAGS=$CFLAGS ./configure ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 10:28 Message: Logged In: YES user_id=696559 BTW: With gcc, I don't get even to the link step: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o Modules/posixmodule.c: In function `posix_stat': Modules/posixmodule.c:1851: `stat' undeclared (first use in this function) Modules/posixmodule.c:1851: (Each undeclared identifier is reported only once Modules/posixmodule.c:1851: for each function it appears in.) Modules/posixmodule.c: In function `posix_plock': Modules/posixmodule.c:2956: warning: implicit declaration of function `plock' Modules/posixmodule.c: In function `posix_lstat': Modules/posixmodule.c:4683: `lstat' undeclared (first use in this function) Modules/posixmodule.c: In function `posix_unsetenv': Modules/posixmodule.c:5431: warning: implicit declaration of function `unsetenv' make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 09:24 Message: Logged In: YES user_id=696559 This is specific for Dec/Compaq/HP compiler. The manpage for cc says: -pthread Directs the linker to use the threadsafe version of any library speci- fied with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.1c-conformant DECthreads inter- faces in libpthread when linking the program. This option also defines the _REENTRANT macro. As I remeber from experience, it's not enough to use it really as LDFLAG supplied to ld. The code has to be compiled with that flag already and therefore I set CC or CFLAGS to contain this value. Same applies for CXX or CXXFLAGS. Actually, there's a configure macro check, I saw it somewhere in documentation on the web. I posted that once into some my bugreport in GNOME bugzilla. You can dig out from there that URL. Unfortunately, bugzilla searches never worked for me. :( As for gcc: $ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure [...] checking whether pthreads are available without options... no checking whether gcc accepts -Kpthread... no [...] checking for --with-dec-threads... no checking for --with-threads... yes checking for _POSIX_THREADS in unistd.h... yes checking cthreads.h usability... no checking cthreads.h presence... no checking for cthreads.h... no checking mach/cthreads.h usability... no checking mach/cthreads.h presence... no checking for mach/cthreads.h... no checking for --with-pth... no checking for pthread_create in -lpthread... yes checking if PTHREAD_SCOPE_SYSTEM is supported... yes checking for pthread_sigmask... yes from config.log: configure:3753: checking whether pthreads are available without options configure:3779: gcc -o conftest -O2 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c -L/usr/l ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 In file included from configure:3763: /usr/include/pthread.h:312:4: #error "Please compile the module including pthread.h with -pthread" configure:3782: $? = 1 configure: program exited with status 1 configure: failed program was: #line 3761 "configure" #include "confdefs.h" #include <pthread.h> void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } configure:3802: result: no So, to conclude, -pthread has to be specified even for gcc/g++. Simply, always on ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 05:34 Message: Logged In: YES user_id=33168 Is this only with the Dec/Compaq/HP compiler (cc/cxx)? Do you know if python links ok with gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 From noreply@sourceforge.net Thu May 22 15:27:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 07:27:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-741310 ] Cannot compile Python-2.3b1 on Tru64Unix 5.1A Message-ID: <E19Ir2x-00081w-00@sc8-sf-web1.sourceforge.net> Bugs item #741310, was opened at 2003-05-21 20:58 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741310&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot compile Python-2.3b1 on Tru64Unix 5.1A Initial Comment: cc -DNDEBUG -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I. -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/./Include -I/software/alpha_dux51/usr/include -I/usr/local/include -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Include -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1 -c /afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Modules/tkappinit.c -o build/temp.osf1-V5.1-alpha-2.3/tkappinit.o cc: Error: /software/alpha_dux51/usr/include/tk.h, line 337: Ill-formed parameter type list. (parmtyplist) typedef int (Tk_OptionParseProc) _ANSI_ARGS_((ClientData clientData, ---------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 142: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_ConfigureWidget _ANSI_ARGS_((Tcl_Interp * interp, -------------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 237: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_DisplayName _ANSI_ARGS_((Tk_Window tkwin)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 327: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_GetAtomName _ANSI_ARGS_((Tk_Window tkwin, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 330: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_GetBinding _ANSI_ARGS_((Tcl_Interp * interp, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 410: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_GetScrollInfo _ANSI_ARGS_((Tcl_Interp * interp, -----------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 479: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOf3DBorder _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 482: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfAnchor _ANSI_ARGS_((Tk_Anchor anchor)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 484: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfBitmap _ANSI_ARGS_((Display * display, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 487: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfCapStyle _ANSI_ARGS_((int cap)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 489: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfColor _ANSI_ARGS_((XColor * colorPtr)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 491: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfCursor _ANSI_ARGS_((Display * display, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 494: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfFont _ANSI_ARGS_((Tk_Font font)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 496: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfImage _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 499: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfJoinStyle _ANSI_ARGS_((int join)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 501: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfJustify _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 504: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfRelief _ANSI_ARGS_((int relief)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 513: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_ParseArgv _ANSI_ARGS_((Tcl_Interp * interp, -------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 960: Ill-formed parameter type list. (parmtyplist) int (*tk_ConfigureWidget) _ANSI_ARGS_((Tcl_Interp * interp, Tk_Window tkwin, Tk_ConfigSpec * specs, int argc, CONST84 char ** argv, char * widgRec, int flags)); /* 29 */ ------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 986: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_DisplayName) _ANSI_ARGS_((Tk_Window tkwin)); /* 55 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1014: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_GetAtomName) _ANSI_ARGS_((Tk_Window tkwin, Atom atom)); /* 83 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1015: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_GetBinding) _ANSI_ARGS_((Tcl_Interp * interp, Tk_BindingTable bindingTable, ClientData object, CONST char * eventStr)); /* 84 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1039: Ill-formed parameter type list. (parmtyplist) int (*tk_GetScrollInfo) _ANSI_ARGS_((Tcl_Interp * interp, int argc, CONST84 char ** argv, double * dblPtr, int * intPtr)); /* 108 */ ----------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1061: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOf3DBorder) _ANSI_ARGS_((Tk_3DBorder border)); /* 130 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1062: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfAnchor) _ANSI_ARGS_((Tk_Anchor anchor)); /* 131 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1063: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfBitmap) _ANSI_ARGS_((Display * display, Pixmap bitmap)); /* 132 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1064: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfCapStyle) _ANSI_ARGS_((int cap)); /* 133 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1065: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfColor) _ANSI_ARGS_((XColor * colorPtr)); /* 134 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1066: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfCursor) _ANSI_ARGS_((Display * display, Tk_Cursor cursor)); /* 135 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1067: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfFont) _ANSI_ARGS_((Tk_Font font)); /* 136 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1068: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfImage) _ANSI_ARGS_((Tk_ImageMaster imageMaster)); /* 137 */ ----^ cc: Severe: More than 30 errors were encountered in the course of compilation. (toomanyerr) running build_scripts creating build/scripts-2.3 copying and adjusting /afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Tools/scripts/pydoc -> build/scripts-2.3 changing mode of build/scripts-2.3/pydoc from 644 to 755 $ ---------------------------------------------------------------------- >Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 16:27 Message: Logged In: YES user_id=696559 Yes, you are right. Reinstalling tcl and tk helped. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 00:29 Message: Logged In: YES user_id=33168 The problem looks to be in tcl/tk. I am able to build on Tru64 5.1 using cc, so I can't diagnose your problem. Can you look into what is causing the problem in tcl/tk. _ANSI_ARGS_ should be defined in tcl.h which should be included. Is this getting a bad value? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741310&group_id=5470 From noreply@sourceforge.net Thu May 22 15:34:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 07:34:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-741310 ] Cannot compile Python-2.3b1 on Tru64Unix 5.1A Message-ID: <E19Ir98-00086d-00@sc8-sf-web1.sourceforge.net> Bugs item #741310, was opened at 2003-05-21 14:58 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741310&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) >Assigned to: Neal Norwitz (nnorwitz) Summary: Cannot compile Python-2.3b1 on Tru64Unix 5.1A Initial Comment: cc -DNDEBUG -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I. -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/./Include -I/software/alpha_dux51/usr/include -I/usr/local/include -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Include -I/afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1 -c /afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Modules/tkappinit.c -o build/temp.osf1-V5.1-alpha-2.3/tkappinit.o cc: Error: /software/alpha_dux51/usr/include/tk.h, line 337: Ill-formed parameter type list. (parmtyplist) typedef int (Tk_OptionParseProc) _ANSI_ARGS_((ClientData clientData, ---------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 142: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_ConfigureWidget _ANSI_ARGS_((Tcl_Interp * interp, -------------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 237: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_DisplayName _ANSI_ARGS_((Tk_Window tkwin)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 327: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_GetAtomName _ANSI_ARGS_((Tk_Window tkwin, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 330: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_GetBinding _ANSI_ARGS_((Tcl_Interp * interp, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 410: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_GetScrollInfo _ANSI_ARGS_((Tcl_Interp * interp, -----------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 479: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOf3DBorder _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 482: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfAnchor _ANSI_ARGS_((Tk_Anchor anchor)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 484: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfBitmap _ANSI_ARGS_((Display * display, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 487: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfCapStyle _ANSI_ARGS_((int cap)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 489: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfColor _ANSI_ARGS_((XColor * colorPtr)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 491: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfCursor _ANSI_ARGS_((Display * display, ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 494: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfFont _ANSI_ARGS_((Tk_Font font)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 496: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfImage _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 499: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfJoinStyle _ANSI_ARGS_((int join)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 501: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfJustify _ANSI_ARGS_(( ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 504: Missing ";". (nosemi) EXTERN CONST84_RETURN char * Tk_NameOfRelief _ANSI_ARGS_((int relief)); ----------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 513: Ill-formed parameter type list. (parmtyplist) EXTERN int Tk_ParseArgv _ANSI_ARGS_((Tcl_Interp * interp, -------------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 960: Ill-formed parameter type list. (parmtyplist) int (*tk_ConfigureWidget) _ANSI_ARGS_((Tcl_Interp * interp, Tk_Window tkwin, Tk_ConfigSpec * specs, int argc, CONST84 char ** argv, char * widgRec, int flags)); /* 29 */ ------------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 986: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_DisplayName) _ANSI_ARGS_((Tk_Window tkwin)); /* 55 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1014: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_GetAtomName) _ANSI_ARGS_((Tk_Window tkwin, Atom atom)); /* 83 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1015: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_GetBinding) _ANSI_ARGS_((Tcl_Interp * interp, Tk_BindingTable bindingTable, ClientData object, CONST char * eventStr)); /* 84 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1039: Ill-formed parameter type list. (parmtyplist) int (*tk_GetScrollInfo) _ANSI_ARGS_((Tcl_Interp * interp, int argc, CONST84 char ** argv, double * dblPtr, int * intPtr)); /* 108 */ ----------------------------^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1061: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOf3DBorder) _ANSI_ARGS_((Tk_3DBorder border)); /* 130 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1062: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfAnchor) _ANSI_ARGS_((Tk_Anchor anchor)); /* 131 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1063: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfBitmap) _ANSI_ARGS_((Display * display, Pixmap bitmap)); /* 132 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1064: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfCapStyle) _ANSI_ARGS_((int cap)); /* 133 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1065: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfColor) _ANSI_ARGS_((XColor * colorPtr)); /* 134 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1066: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfCursor) _ANSI_ARGS_((Display * display, Tk_Cursor cursor)); /* 135 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1067: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfFont) _ANSI_ARGS_((Tk_Font font)); /* 136 */ ----^ cc: Error: /software/alpha_dux51/usr/include/tkDecls.h, line 1068: Missing type specifier or type qualifier. (missingtype) CONST84_RETURN char * (*tk_NameOfImage) _ANSI_ARGS_((Tk_ImageMaster imageMaster)); /* 137 */ ----^ cc: Severe: More than 30 errors were encountered in the course of compilation. (toomanyerr) running build_scripts creating build/scripts-2.3 copying and adjusting /afs/gsf.de/sources/ev56/libgnomeui-2.2.0.1/Python-2.3b1/Tools/scripts/pydoc -> build/scripts-2.3 changing mode of build/scripts-2.3/pydoc from 644 to 755 $ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 10:34 Message: Logged In: YES user_id=33168 Ok, I'm closing this bug. If you still have a problem, please re-open this report or a new one. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 10:27 Message: Logged In: YES user_id=696559 Yes, you are right. Reinstalling tcl and tk helped. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 18:29 Message: Logged In: YES user_id=33168 The problem looks to be in tcl/tk. I am able to build on Tru64 5.1 using cc, so I can't diagnose your problem. Can you look into what is causing the problem in tcl/tk. _ANSI_ARGS_ should be defined in tcl.h which should be included. Is this getting a bad value? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741310&group_id=5470 From noreply@sourceforge.net Thu May 22 15:48:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 07:48:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-741171 ] pdb crashes when enabling a non-existing breakpoint Message-ID: <E19IrNE-0004pa-00@sc8-sf-web4.sourceforge.net> Bugs item #741171, was opened at 2003-05-21 10:56 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741171&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Heike C. Zimmerer (hcz) >Assigned to: A.M. Kuchling (akuchling) Summary: pdb crashes when enabling a non-existing breakpoint Initial Comment: pdb exits when enabling a non-existing breakpoint. This happens on 2.2.2 and on 2.3a0: $ echo > x.py $ pdb x.py > <string>(0)?() (Pdb) enable 1 Traceback (most recent call last): File "/usr/lib/python2.2/pdb.py", line 959, in ? run('execfile(' + `filename` + ')') [...] File "/usr/lib/python2.2/cmd.py", line 200, in onecmd return func(arg) File "/usr/lib/python2.2/pdb.py", line 370, in do_enable bp = bdb.Breakpoint.bpbynumber[int(i)] IndexError: list index out of range $ ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-05-22 10:48 Message: Logged In: YES user_id=11375 Fixed in revision 1.65 of pdb.py. Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741171&group_id=5470 From noreply@sourceforge.net Thu May 22 16:32:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 08:32:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-741806 ] test_long failure Message-ID: <E19Is2z-0000Nj-00@sc8-sf-web2.sourceforge.net> Bugs item #741806, was opened at 2003-05-22 17:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test_long failure Initial Comment: $ python Lib/test/test_long.pyc long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow Traceback (most recent call last): File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 442, in ? test_float_overflow() File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 394, in test_float_overflow eval(test, namespace) File "<string>", line 0, in ? ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 $ This happens on Tru64Unix 5.1A, cc/cxx compiled binaries. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 From noreply@sourceforge.net Thu May 22 16:54:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 08:54:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-741806 ] test_long failure Message-ID: <E19IsOr-00006A-00@sc8-sf-web4.sourceforge.net> Bugs item #741806, was opened at 2003-05-22 17:32 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test_long failure Initial Comment: $ python Lib/test/test_long.pyc long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow Traceback (most recent call last): File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 442, in ? test_float_overflow() File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 394, in test_float_overflow eval(test, namespace) File "<string>", line 0, in ? ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 $ This happens on Tru64Unix 5.1A, cc/cxx compiled binaries. ---------------------------------------------------------------------- >Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 17:54 Message: Logged In: YES user_id=696559 ${ac_dA}SIZEOF_LONG${ac_dB}SIZEOF_LONG${ac_dC}8${ac_dD} ${ac_dA}HAVE_LONG_LONG${ac_dB}HAVE_LONG_LONG${ac_dC}1${ac_dD} ${ac_dA}SIZEOF_LONG_LONG${ac_dB}SIZEOF_LONG_LONG${ac_dC}8${ac_dD} ${ac_uA}SIZEOF_LONG${ac_uB}SIZEOF_LONG${ac_uC}8${ac_uD} ${ac_uA}HAVE_LONG_LONG${ac_uB}HAVE_LONG_LONG${ac_uC}1${ac_uD} ${ac_uA}SIZEOF_LONG_LONG${ac_uB}SIZEOF_LONG_LONG${ac_uC}8${ac_uD} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 From noreply@sourceforge.net Thu May 22 17:25:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 09:25:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-741843 ] curses support on Python-2.3b1/Tru64Unix 5.1A Message-ID: <E19IssN-0003nA-00@sc8-sf-web3.sourceforge.net> Bugs item #741843, was opened at 2003-05-22 18:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: curses support on Python-2.3b1/Tru64Unix 5.1A Initial Comment: I have managed to compile python on Tru64Unix, but am curious when I rerun "make", I get: make case $MAKEFLAGS in \ *-s*) CC='cc -pthread' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; \ *) CC='cc -pthread' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; \ esac running build running build_ext building '_locale' extension cc -pthread -DNDEBUG -O -Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include -I/software/@sys/usr/include -I/usr/local/include -I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c /mnt/Python-2.3b1/Modules/_localemodule.c -o build/temp.osf1-V5.1-alpha-2.3/_localemodule.o ld -shared -expect_unresolved * build/temp.osf1-V5.1-alpha-2.3/_localemodule.o -L/software/@sys/usr/lib -L/usr/local/lib -o build/lib.osf1-V5.1-alpha-2.3/_locale.so *** WARNING: renaming "_locale" since importing it failed: dlopen: build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol "libintl_gettext" unresolved building '_curses' extension cc -pthread -DNDEBUG -O -Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include -I/software/@sys/usr/include -I/usr/local/include -I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c /mnt/Python-2.3b1/Modules/_cursesmodule.c -o build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o ld -shared -expect_unresolved * build/temp.osf1-V5.1-alpha-2.3/_cursesmodule.o -L/software/@sys/usr/lib -L/usr/local/lib -lncurses -o build/lib.osf1-V5.1-alpha-2.3/_curses.so *** WARNING: renaming "_curses" since importing it failed: dlopen: build/lib.osf1-V5.1-alpha-2.3/_curses.so: symbol "_acs_map" unresolved building '_curses_panel' extension cc -pthread -DNDEBUG -O -Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include -I/software/@sys/usr/include -I/usr/local/include -I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c /mnt/Python-2.3b1/Modules/_curses_panel.c -o build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o cc: Severe: /mnt/Python-2.3b1/Modules/_curses_panel.c, line 17: Cannot find file <panel.h> specified in #include directive. (noinclfilef) #include <panel.h> -^ running build_scripts This looks suspicious. I have ncurses available on the system too, also termcap I see that ncurses isn't found because newer version are in $prefix/include/ncurses/ and not anymore in $prefix/include/. There configure fails to detect them. So, I have to configure as: F77=f77 F90=f90 CC="cc -pthread" CXX="cxx -pthread" CFLAGS="$CFLAGS -pthread -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses" CPPFLAGS=$CFLAGS CXXFLAGS=$CFLAGS ./configure --prefix=/software/@sys/usr --host=alphaev56-dec-osf5.1 --with-dec-threads --enable-large-file But even in this case, CPPFLAGS weren't propagated to Makefiles: cc -pthread -DNDEBUG -O -Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include -I/software/@sys/usr/include -I/usr/local/include -I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c /mnt/Python-2.3b1/Modules/_curses_panel.c -o build/temp.osf1-V5.1-alpha-2.3/_curses_panel.o cc: Severe: /mnt/Python-2.3b1/./Include/py_curses.h, line 16: Cannot find file <ncurses.h> specified in #include directive. (noinclfilef) #include <ncurses.h> -^ Ooops! Not propagated, they are NOT USED! See config.status: s,@CXX@,cxx -pthread,;t t s,@MAINOBJ@,python.o,;t t s,@EXEEXT@,,;t t s,@CC@,cc -pthread,;t t s,@CFLAGS@,-O2 -arch ev56 -pthread -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses,;t t s,@LDFLAGS@,,;t t s,@CPPFLAGS@,-O2 -arch ev56 -pthread -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses,;t t s,@ac_ct_CC@,,;t t s,@OBJEXT@,o,;t t s,@CPP@,cc -pthread -E,;t t And during build I still see: case $MAKEFLAGS in \ *-s*) CC='cc -pthread -O2 -arch ev56 -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; \ *) CC='cc -pthread -O2 -arch ev56 -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses' LDSHARED='ld -shared -expect_unresolved "*"' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; \ esac running build running build_ext building '_locale' extension cc -pthread -O2 -arch ev56 -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses -DNDEBUG -O -Olimit 1500 -I. -I/mnt/Python-2.3b1/./Include -I/software/@sys/usr/include -I/usr/local/include -I/mnt/Python-2.3b1/Include -I/mnt/Python-2.3b1 -c /mnt/Python-2.3b1/Modules/_localemodule.c -o build/temp.osf1-V5.1-alpha-2.3/_localemodule.o ld -shared -expect_unresolved * build/temp.osf1-V5.1-alpha-2.3/_localemodule.o -L/software/@sys/usr/lib -L/usr/local/lib -o build/lib.osf1-V5.1-alpha-2.3/_locale.so *** WARNING: renaming "_locale" since importing it failed: dlopen: build/lib.osf1-V5.1-alpha-2.3/_locale.so: symbol "libintl_gettext" unresolved running build_scripts I've reinstalled gettext/libiconv/ncurses, but no difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741843&group_id=5470 From noreply@sourceforge.net Thu May 22 19:11:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 11:11:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-692776 ] new.function() leads to segfault Message-ID: <E19IuWv-00087q-00@sc8-sf-web2.sourceforge.net> Bugs item #692776, was opened at 2003-02-25 08:04 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692776&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jp Calderone (kuran) Assigned to: Jeremy Hylton (jhylton) Summary: new.function() leads to segfault Initial Comment: If a code object which requires a closure is passed to new.function(), a segfault (Python/ceval.c:2578). This seems to be fixed in 2.3. Attached is a short code example that demonstrates the behavior. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-22 18:11 Message: Logged In: YES user_id=31392 Backported for 2.2.3. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-04-09 18:57 Message: Logged In: YES user_id=31392 I think I can swap in the state without too much pain. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-09 10:48 Message: Logged In: YES user_id=6656 Jeremy, is this easy for you to fix? It's fiddlier than I expected. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-02-25 09:31 Message: Logged In: YES user_id=6656 You're right. I guess the fix is to backport the extra 'closure' argument from 2.3. I'll look into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692776&group_id=5470 From noreply@sourceforge.net Thu May 22 19:33:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 11:33:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: <E19IusF-0002Ca-00@sc8-sf-web1.sourceforge.net> Bugs item #549151, was opened at 2002-04-26 17:04 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=261020 I tested the 301 behaviour of MSIE 5.00 on wine, and Mozilla Firebird 0.6. Both redirect POST to GET (without asking for user confirmation) on a 301 redirect, as expected, so it's probably justified to follow through with the 301 changes we discussed (summarised in my last message, along with a couple of related changes; item 1 has already been done). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 13:45 Message: Logged In: YES user_id=261020 Sorry for all these tiny updates. Summary of what remains to be done: 1. Apply Guido's patch for urllib.py: guido.txt. The docs are already correct. 2. 301 in response to POST is still not redirected in urllib2. urllib2.py.patch3 fixes that (note patch3, not patch2). It also removes my Request.get_method method (which now seems like overkill, as well as breaking the URL scheme-independence of Request). Also fixes an exception message. 3. liburllib2.tex.patch2 updates the docs to reflect the changes in urllib2.py.patch3, rephrases a note and adds a missing method description. 4. liburllib.tex.patch2: trivial rewording of docs for clarity. 5. Backport above changes to 2.2 bugfix branch. Jeremy in CVS: > The latest changes to the redirect handler couldn't possibly have been > tested, because they did not compute a newurl and failed with a > NameError. The __name__ == "__main__": block has a test for > redirects. Ah. The tests are preceeded by a warning about only working from a particular set of hosts: I mis-remembered, thinking that applied to *all* the tests. Sorry. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 01:14 Message: Logged In: YES user_id=261020 OK, I can't test IE, because Windows doesn't have a proper loopback adapter, and my Windows machine is disconnected. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 15:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 21:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 01:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 18:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 09:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 16:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 16:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 21:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 21:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 21:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 20:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Thu May 22 19:34:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 11:34:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-735515 ] urllib / urllib2 should cache 301 redirections Message-ID: <E19Iuu0-0002I6-00@sc8-sf-web1.sourceforge.net> Bugs item #735515, was opened at 2003-05-10 01:21 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735515&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib / urllib2 should cache 301 redirections Initial Comment: urllib / urllib2 should cache the results of 301 (permanent) redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC (2616, section 10.3.2, first para) says SHOULD happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735515&group_id=5470 From noreply@sourceforge.net Thu May 22 22:54:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:54:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-662840 ] configure script fails with wchat_t size. Message-ID: <E19Iy0f-0002Xl-00@sc8-sf-web2.sourceforge.net> Bugs item #662840, was opened at 2003-01-05 17:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Nobody/Anonymous (nobody) Summary: configure script fails with wchat_t size. Initial Comment: Python version 2.3a1 System RH 7.3 Compiler: gcc 3.2.1 The configure script bails out when trying to determain the size of wchar_t. The configure runs OK with gcc 2.96. . . . checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:54 Message: Logged In: YES user_id=33168 Nadav, do you still have this problem with 2.3b1? Is this a duplicate as indicated in the comments? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-01 20:45 Message: Logged In: YES user_id=33168 Seems to be a duplicate of 678723 (or at least related, both are redhat 7.3). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 17:01 Message: Logged In: YES user_id=21627 I see. The problem lies in these lines configure:15806: ./conftest ./configure: line 1: 6876 Segmentation fault ./conftest$ac_exeext Now, it is not clear why the test program (printed below these lines) could possible cause a segmentation fault - unless there is a bug in the compiler. So I would conclude this to be a gcc bug, on this configuration. It would be possible to track this further down, but that would require access to the machine, using a debugger, etc. ---------------------------------------------------------------------- Comment By: Nadav Horesh (nadavhoresh) Date: 2003-01-06 15:02 Message: Logged In: YES user_id=75473 Further info: On the same system (RH7.3+gcc3.2.1+PIII) I compliled python 2.2.2 without any problems. On another system: RH8.0 + gcc3.2.1 + dual PIII --- the configure script concluded without errors. I didn't try to compile though. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 18:12 Message: Logged In: YES user_id=21627 Can you please attach the resulting config.log? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 From noreply@sourceforge.net Thu May 22 23:20:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:20:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files Message-ID: <E19IyPv-0003jv-00@sc8-sf-web3.sourceforge.net> Bugs item #602345, was opened at 2002-08-30 06:13 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Skip Montanaro (montanaro) Summary: option for not writing .py[co] files Initial Comment: [destilled from http://bugs.debian.org/96111] Currently python tries to write the .py[co] files even in situations, where it will fail, like on read-only mounted file systems. In other situations I don't want python trying to write the compiled files, i.e. having installed the modules as root as part of a distribution, compiled them correctly, there is no need to write them. Or compiling .py files which are configuration files. Is it reasonable to add an option to python (--dont-write-compiled-files) to the interpreter, which doesn't write them? This would not affect existing code at all. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-05-22 17:20 Message: Logged In: YES user_id=44345 I have a c.l.py message buried in my python mailbox which raises some Windows-related problems. I have yet to figure that out, but they looked somewhat difficult on first glance. I'll try to dredge that up and attach it to this id. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:03 Message: Logged In: YES user_id=33168 I think Skip now owns this because of his PEP. :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 00:50 Message: Logged In: YES user_id=357491 PEP 304 now handles this situation. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-12 15:39 Message: Logged In: YES user_id=33168 You are correct about the patch being incomplete. I still have to do all the doc. I hadn't thought about an env't variable or variable in sys. Both are certainly reasonable. I will update the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-12 13:47 Message: Logged In: YES user_id=21627 The patch looks good, but is surely incomplete: there should be patches to the documentation, in particular to the man page. It might be also desirable to parallel this option with an environment variable, and/or to expose it writable through the sys module. With the environment variable, people could run Python scripts that won't create .pyc files (as #! /usr/bin/env python does not allow for further command line options). With the API, certain applications could declare that they never want to write .pyc files as they expect to run in parallel with itself, and might cause .pyc conflicts. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 10:39 Message: Logged In: YES user_id=6380 I think it's a good idea, but please use a single upper case letter for the option. Python doesn't support long options and I'm not about to start doing so. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 18:30 Message: Logged In: YES user_id=33168 Guido, do you think this is a good idea? If so, assign back to me and I'll work up a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 From noreply@sourceforge.net Thu May 22 23:15:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:15:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-651701 ] Bozo getstate w/ slots overrides base Message-ID: <E19IyLj-0005Gy-00@sc8-sf-web1.sourceforge.net> Bugs item #651701, was opened at 2002-12-10 18:10 Message generated for change (Comment added) made by nnorwitz 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: Neal Norwitz (nnorwitz) Date: 2003-05-22 18: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 18: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 17: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@sourceforge.net Thu May 22 23:12:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:12:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-456398 ] strange IRIX test_re/test_sre failure Message-ID: <E19IyI6-0007dc-00@sc8-sf-web4.sourceforge.net> Bugs item #456398, was opened at 2001-08-29 00:56 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=456398&group_id=5470 Category: Regular Expressions Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 4 Submitted By: Andrew Dalke (dalke) Assigned to: Fredrik Lundh (effbot) Summary: strange IRIX test_re/test_sre failure Initial Comment: The test_re and test_sre regression tests cause a core dump with the CVS version of Python. If I run the file directly I don't get the core dump. test_pyclbr test_pyexpat test test_pyexpat skipped -- No module named pyexpat test_quopri test_re make: *** [test] Segmentation fault (core dumped) ./python -E -tt ./Lib/test/regrtest.py -l ^C % % ./python -E -tt ./Lib/test/test_re.py Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite % This is under an IRIX 6.4 machine, which is several years old. Python is compiled with gcc 2.95.2 but using the vendor's assembler. The assembler is also out of date. There were known problems with in 1.5.2 where the optimizer broke the pcre module. So I recompiled _sre.c with "-g". That did not fix the problem. Here's the stack trace from the core file. > 0 mark_save(state = <no such address>, lo = <no such address>, hi = <no such ad dress>) ["/usr2/people/dalke/cvses/python/dist/src/./Modules/_s re.c":280, 0x100a1e 2c] 1 sre_match(state = 0x7fff1200, pattern = 0x104ec55a, level = 1357) ["/usr2/peo ple/dalke/cvses/python/dist/src/Modules/_sre.c":1053, 0x100a44b4] 2 sre_match(state = 0x7fff1200, pattern = 0x104ec55a, level = 1356) ["/usr2/peo ple/dalke/cvses/python/dist/src/Modules/_sre.c":1057, 0x100a4504] Guessing it's in the "recursion limit" test. I don't know if the problem is in _sre.c or in the IRIX libraries. I don't have access to a newer version of IRIX. I tried to force the core dump to occur without having to go through the whole regression suite. That doesn't work, which is itself suspecious. % ./python -E -tt ./Lib/test/regrtest.py -l test_re test_re 1 test OK. % ./python -E -tt ./Lib/test/regrtest.py -l test_array test_re test_array test_re All 2 tests OK. % ./python -E -tt ./Lib/test/regrtest.py -l test_array test_re test_re test_array test_re test_re All 3 tests OK. % I get the same failures with test_sre. Andrew dalke@dalkescientific.com ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 18:09 Message: Logged In: YES user_id=33168 Closing this report at the test pass for me on IRIX 6.5 and there's no further input. If a bug persists, please open a new report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:40 Message: Logged In: YES user_id=33168 Andrew, is this still a problem? How big is the stack? Could the problem have been that the max stack size was exceeded which caused the crash? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=456398&group_id=5470 From noreply@sourceforge.net Thu May 22 22:50:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:50:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-678723 ] ./configure fails w/error: cannot compute sizeof (wchar_t), Message-ID: <E19IxxD-000498-00@sc8-sf-web1.sourceforge.net> Bugs item #678723, was opened at 2003-02-01 12:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Jeff Stephens (jeffste) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure fails w/error: cannot compute sizeof (wchar_t), Initial Comment: I am running RH 7.3, kernel 2.4.18-19.7.x, and gcc-2.96-113. I attempted to configure python-2.3a1 as follows: ./configure --enable-shared --with-threads --with-pth Got the following error: checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:50 Message: Logged In: YES user_id=33168 Is this still a problem with the current beta? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 08:24 Message: Logged In: YES user_id=21627 Feel free to put a note into the README. However, I think this is a pilot error: If the user specifies --with-pth, but does not have pth properly installed, then configure is entitled to fail in strange ways. If --with or --enable is specified, it should be taken as overriding whatever configure thinks is right, so those command options must be followed blindly. Perhaps a general note "read config.log if configure fails" would be appropriate. It would be good if Jeff could report whether he ran into the same problem (pth not properly installed). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-15 08:11 Message: Logged In: YES user_id=11375 Good suggestion; installing libpth-dev lets configure run without problems. So the simplest fix for this bug is probably just adding a note to the README warning people to have the appropriate .so installed. Or should configure check for a linkable libfoo.so? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-14 16:33 Message: Logged In: YES user_id=21627 Can you give the precise name of the .so file you have in /usr/lib? If it is usr/lib/libpth.so.14, then it is irrelevant that ldconfig finds it: /usr/bin/ld won't use that file for linking. You probably need to install libpth-dev. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 11:04 Message: Logged In: YES user_id=11375 I can replicate this problem on my Debian machine. config.log attached. 'gcc -o conftest -g -O2 config.c -lpth -lrt -ldl' reports the following error: '/usr/bin/ld: cannot find -lpth'. This is very odd, because I've got the libpth14 package installed, there's a .so in /usr/lib, ldconfig find it, etc. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 11:04 Message: Logged In: YES user_id=11375 Let's try that attachment again. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 10:42 Message: Logged In: YES user_id=21627 It would be good if you could attach the config.log that you got when it failed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-01 20:46 Message: Logged In: YES user_id=33168 Jeff, I think we should try to fix this. It looks like a duplicate of 662840. It would be great if you can help debug this further. The problem seems to be related to redhat 7.3. The other bug which fails exactly the same way is using gcc 3.2 and doesn't mention config options (although they may be used). ---------------------------------------------------------------------- Comment By: Jeff Stephens (jeffste) Date: 2003-02-01 13:33 Message: Logged In: YES user_id=702289 I reran ./configure several times, varying the options, and found that this error only occurs when the option "--with-pth" is included. For example: ./configure --enable-shared --with-pth #error occurs ./configure --enable-shared --with-threads #error does NOT occur I don't know whether this is a bug or not, so I am leaving it to the experts to say yea or nay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 From noreply@sourceforge.net Thu May 22 22:39:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:39:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-703066 ] os.utime can fail with TypeError Message-ID: <E19IxmA-0003ci-00@sc8-sf-web1.sourceforge.net> Bugs item #703066, was opened at 2003-03-13 11:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703066&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime can fail with TypeError Initial Comment: Occasionally os.utime can fail with a TypeError: # python Python 2.2.2 (#1, Dec 16 2002, 02:51:47) [GCC 3.2.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os,time >>> os.utime("/backup/test/interhost/ace/.maildir-sent/cur/rdiff-backup.tmp.1980", ... (time.time(), 1038064008)); Traceback (most recent call last): File "<stdin>", line 2, in ? TypeError: utime() arg 2 must be a tuple (atime, mtime) if one of the elements in the time pair is a float and not a long. Strangely it seems to work sporadically. It may just be a documentation problem -- add a note in the docs saying longs are required, and then have the TypeError say: TypeError: utime() arg 2 must be a tuple of longs (atime, mtime) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:39 Message: Logged In: YES user_id=33168 Ben, I can't reproduce this problem with 2.2.3 or 2.3. Can you verify this is still a problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703066&group_id=5470 From noreply@sourceforge.net Thu May 22 22:23:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:23:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19IxXH-0005ki-00@sc8-sf-web4.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 16:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 12:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 07:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 06:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 17:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Thu May 22 22:22:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:22:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-705295 ] Error when using PyZipFile to create archive Message-ID: <E19IxVi-0001Mm-00@sc8-sf-web3.sourceforge.net> Bugs item #705295, was opened at 2003-03-17 18:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705295&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: Error when using PyZipFile to create archive Initial Comment: I get the following trace back while using the PyZipFile class to create zip import files. Traceback (most recent call last): File "../fsmGenerate.py", line 125, in ? main() File "../fsmGenerate.py", line 121, in main generate(inFileName, outName, app, gui, schema, zip) File "../fsmGenerate.py", line 56, in generate outZip.write(name) File "/usr/local/lib/python2.3/zipfile.py", line 427, in write self.fp.write(zinfo.FileHeader()) File "/usr/local/lib/python2.3/zipfile.py", line 167, in FileHeader fileHeader = '%s%s%s' % (header, self.filename, self.extra) UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 10: ordinal not in range(128) This error occurs intermitently. It seems to be related to the time. Looking in file Lib/zipfile.py, it appears that the call to struct.pack() in method ZipInfo.FileHeader() is creating a string containing bytes with values > 0x7F. I believe that these values are coming from local variable dostime in ZipInfo.FileHeader(). I'm using Python 2.3a2, built from source on Linux. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:22 Message: Logged In: YES user_id=33168 I'm closing this bug report since it can't be reproduced. If you have another bug, please open a new bug report. ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2003-04-02 20:34 Message: Logged In: YES user_id=629965 I can no longer reproduce this bug. I'm the one who originally submitted this bug report. There must have been a bug in my original code. The test I'm using now executes with no problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705295&group_id=5470 From noreply@sourceforge.net Thu May 22 22:13:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:13:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-736892 ] forcing function to act like an unbound method dumps core Message-ID: <E19IxN0-00028T-00@sc8-sf-web1.sourceforge.net> Bugs item #736892, was opened at 2003-05-13 03:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Paul Du Bois (df-dubois) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: forcing function to act like an unbound method dumps core Initial Comment: Using ActivePython, v2.2.2 I was reading PEP252 and trying stupid things, like this: k [ 0:51] 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. >>> def func(): pass ... >>> f = func.__get__() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: function takes at least 1 argument (0 given) >>> f = func.__get__(None) >>> f() # This gives a reasonable result Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unbound method func() must be called with ? instance as first argument (got nothing instead) >>> f(1) # This crashes accessing a null pointer ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:13 Message: Logged In: YES user_id=33168 Bumping priority. Barry, do you want to handle this for 2.2.3? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 14:27 Message: Logged In: YES user_id=11375 It seems to be fixed in 2.3CVS: >>> f = func.__get__(None) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: __get__(None, None) is invalid The fix needs to be backported to the 2.2 branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 From noreply@sourceforge.net Thu May 22 22:08:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:08:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-741806 ] test_long failure Message-ID: <E19IxJ0-0001rq-00@sc8-sf-web1.sourceforge.net> Bugs item #741806, was opened at 2003-05-22 11:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test_long failure Initial Comment: $ python Lib/test/test_long.pyc long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow Traceback (most recent call last): File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 442, in ? test_float_overflow() File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 394, in test_float_overflow eval(test, namespace) File "<string>", line 0, in ? ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 $ This happens on Tru64Unix 5.1A, cc/cxx compiled binaries. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:08 Message: Logged In: YES user_id=33168 Patch 719359 should fix this problem. Can you test this patch? ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 11:54 Message: Logged In: YES user_id=696559 ${ac_dA}SIZEOF_LONG${ac_dB}SIZEOF_LONG${ac_dC}8${ac_dD} ${ac_dA}HAVE_LONG_LONG${ac_dB}HAVE_LONG_LONG${ac_dC}1${ac_dD} ${ac_dA}SIZEOF_LONG_LONG${ac_dB}SIZEOF_LONG_LONG${ac_dC}8${ac_dD} ${ac_uA}SIZEOF_LONG${ac_uB}SIZEOF_LONG${ac_uC}8${ac_uD} ${ac_uA}HAVE_LONG_LONG${ac_uB}HAVE_LONG_LONG${ac_uC}1${ac_uD} ${ac_uA}SIZEOF_LONG_LONG${ac_uB}SIZEOF_LONG_LONG${ac_uC}8${ac_uD} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 From noreply@sourceforge.net Thu May 22 22:14:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:14:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-737947 ] Failed assert in stringobject.c Message-ID: <E19IxNw-0005GZ-00@sc8-sf-web4.sourceforge.net> Bugs item #737947, was opened at 2003-05-14 18:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None >Priority: 7 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Failed assert in stringobject.c Initial Comment: Here's how to reproduce the problem: [~]> cat test.py import readline readline.get_completer_delims() [~]> echo 'execfile("test.py");print 10' | python python: Objects/stringobject.c:111: PyString_FromString: Assertion `str !=((void *)0)' failed. Abort This was tested with 2.2.1 under RedHat 8.0. On c.l.py, a Mandrake 9.0 (py2.2.2) user reported a segfault with the same. Martin reported not seeing the problem with 2.3b1. However, others suggested still filing it for a possible backport, and also in case the fix was accidental. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:14 Message: Logged In: YES user_id=33168 Barry, should this be handled for 2.2.3? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-14 22:28 Message: Logged In: YES user_id=33168 revision 2.54 in Modules/readline.c fixed this problem. Patch #512981: Update readline input stream on sys.stdin/out change. The patch must be modified for 2.2.3 because there is an API change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 From noreply@sourceforge.net Fri May 23 05:38:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 21:38:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-736892 ] forcing function to act like an unbound method dumps core Message-ID: <E19J4KO-00022u-00@sc8-sf-web1.sourceforge.net> Bugs item #736892, was opened at 2003-05-13 03:57 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 7 Submitted By: Paul Du Bois (df-dubois) Assigned to: Barry A. Warsaw (bwarsaw) Summary: forcing function to act like an unbound method dumps core Initial Comment: Using ActivePython, v2.2.2 I was reading PEP252 and trying stupid things, like this: k [ 0:51] 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. >>> def func(): pass ... >>> f = func.__get__() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: function takes at least 1 argument (0 given) >>> f = func.__get__(None) >>> f() # This gives a reasonable result Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unbound method func() must be called with ? instance as first argument (got nothing instead) >>> f(1) # This crashes accessing a null pointer ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-23 00:38 Message: Logged In: YES user_id=12800 Yes, let's try to get this fix into 2.2.3 final. I'll look at it if nobody beats me to it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:13 Message: Logged In: YES user_id=33168 Bumping priority. Barry, do you want to handle this for 2.2.3? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 14:27 Message: Logged In: YES user_id=11375 It seems to be fixed in 2.3CVS: >>> f = func.__get__(None) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: __get__(None, None) is invalid The fix needs to be backported to the 2.2 branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 From noreply@sourceforge.net Thu May 22 22:46:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:46:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-697985 ] Move gmtime function from calendar to time module Message-ID: <E19Ixte-0002Hj-00@sc8-sf-web3.sourceforge.net> Bugs item #697985, was opened at 2003-03-05 08:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Move gmtime function from calendar to time module Initial Comment: The gmtime function in the calendar module would be much more logical to have in the time module, since it manipulates tm tuples and unix timestamps, which the other functions in time do, but no other functions in calendar. Related to bug #697983 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:46 Message: Logged In: YES user_id=33168 The gmtime function is in time, not calendar. Did you mean the opposite that you believe gmtime should be in calendar? gmtime comes from the C version which is the purpose of time, to expose C functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 From noreply@sourceforge.net Thu May 22 23:01:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:01:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-644345 ] Poor error message for augmented assign Message-ID: <E19Iy7a-0002rE-00@sc8-sf-web2.sourceforge.net> Bugs item #644345, was opened at 2002-11-26 16:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644345&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Neal Norwitz (nnorwitz) Summary: Poor error message for augmented assign Initial Comment: >>> [1,2] += [2,3] SyntaxError: augmented assign to list not possible A similar error message is generated when augmented assignment is used on tuple literals. This error message is desceptive because augmented assignment is allowed on both of those types. I would change the message to: SyntaxError: can't assign to literal I may generate a patch for this, but not anytime soon. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 18:01 Message: Logged In: YES user_id=33168 Checked in Python/compile.c 2.289 to add the word literal Hopefully this is clearer. This change could be backported, if anyone cares. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-22 00:05 Message: Logged In: YES user_id=357491 I like Neal's suggestion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 08:16 Message: Logged In: YES user_id=33168 Jeremy, do you agree? How about adding the word literal to the error msg, so it reads: * augmented assign to literal list not possible ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644345&group_id=5470 From noreply@sourceforge.net Thu May 22 23:03:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:03:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files Message-ID: <E19Iy9T-0007L0-00@sc8-sf-web4.sourceforge.net> Bugs item #602345, was opened at 2002-08-30 07:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) >Assigned to: Skip Montanaro (montanaro) Summary: option for not writing .py[co] files Initial Comment: [destilled from http://bugs.debian.org/96111] Currently python tries to write the .py[co] files even in situations, where it will fail, like on read-only mounted file systems. In other situations I don't want python trying to write the compiled files, i.e. having installed the modules as root as part of a distribution, compiled them correctly, there is no need to write them. Or compiling .py files which are configuration files. Is it reasonable to add an option to python (--dont-write-compiled-files) to the interpreter, which doesn't write them? This would not affect existing code at all. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 18:03 Message: Logged In: YES user_id=33168 I think Skip now owns this because of his PEP. :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 01:50 Message: Logged In: YES user_id=357491 PEP 304 now handles this situation. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-12 16:39 Message: Logged In: YES user_id=33168 You are correct about the patch being incomplete. I still have to do all the doc. I hadn't thought about an env't variable or variable in sys. Both are certainly reasonable. I will update the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-12 14:47 Message: Logged In: YES user_id=21627 The patch looks good, but is surely incomplete: there should be patches to the documentation, in particular to the man page. It might be also desirable to parallel this option with an environment variable, and/or to expose it writable through the sys module. With the environment variable, people could run Python scripts that won't create .pyc files (as #! /usr/bin/env python does not allow for further command line options). With the API, certain applications could declare that they never want to write .pyc files as they expect to run in parallel with itself, and might cause .pyc conflicts. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 11:39 Message: Logged In: YES user_id=6380 I think it's a good idea, but please use a single upper case letter for the option. Python doesn't support long options and I'm not about to start doing so. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 19:30 Message: Logged In: YES user_id=33168 Guido, do you think this is a good idea? If so, assign back to me and I'll work up a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 From noreply@sourceforge.net Thu May 22 22:55:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:55:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-663782 ] test_socket test_unicode_file fail on 2.3a1 on winNT Message-ID: <E19Iy1k-0004NJ-00@sc8-sf-web1.sourceforge.net> Bugs item #663782, was opened at 2003-01-07 10:58 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_socket test_unicode_file fail on 2.3a1 on winNT Initial Comment: This happens after installing 2.3a1 on winNT 4 sp6. D:\apps\Python23>python D:\apps\Python23\Lib\test\test_socket.py testCrucialConstants (__main__.GeneralModuleTests) ... ok testDefaultTimeout (__main__.GeneralModuleTests) ... ok testGetServByName (__main__.GeneralModuleTests) ... ok testGetSockOpt (__main__.GeneralModuleTests) ... ok testHostnameRes (__main__.GeneralModuleTests) ... ok testInterpreterCrash (__main__.GeneralModuleTests) ... ok testNtoH (__main__.GeneralModuleTests) ... ok testRefCountGetNameInfo (__main__.GeneralModuleTests) ... ok testSendAfterClose (__main__.GeneralModuleTests) ... ok testSetSockOpt (__main__.GeneralModuleTests) ... ok testSockName (__main__.GeneralModuleTests) ... ok testSocketError (__main__.GeneralModuleTests) ... ok testFromFd (__main__.BasicTCPTest) ... ok testOverFlowRecv (__main__.BasicTCPTest) ... ok testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok testRecv (__main__.BasicTCPTest) ... ok testRecvFrom (__main__.BasicTCPTest) ... ok testSendAll (__main__.BasicTCPTest) ... ok testShutdown (__main__.BasicTCPTest) ... ok testRecvFrom (__main__.BasicUDPTest) ... ok testSendtoAndRecv (__main__.BasicUDPTest) ... ok testAccept (__main__.NonBlockingTCPTests) ... FAIL ERROR testConnect (__main__.NonBlockingTCPTests) ... ok testRecv (__main__.NonBlockingTCPTests) ... ok testSetBlocking (__main__.NonBlockingTCPTests) ... ok testFullRead (__main__.FileObjectClassTestCase) ... ok testReadline (__main__.FileObjectClassTestCase) ... ok testSmallRead (__main__.FileObjectClassTestCase) ... ok testUnbufferedRead (__main__.FileObjectClassTestCase) ... ok testFullRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testUnbufferedReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok testFullRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testReadline (__main__.LineBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testFullRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testReadline (__main__.SmallBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok ====================================================================== ERROR: testAccept (__main__.NonBlockingTCPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 117, in _tearDown self.fail(msg) File "D:\apps\Python23\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: (10061, 'Connection refused') ====================================================================== FAIL: testAccept (__main__.NonBlockingTCPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 475, in testAccept self.fail("Error trying to do non-blocking accept.") File "D:\apps\Python23\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: Error trying to do non-blocking accept. ---------------------------------------------------------------------- Ran 42 tests in 2.204s FAILED (failures=1, errors=1) Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 632, in ? test_main() File "D:\apps\Python23\Lib\test\test_socket.py", line 629, in test_main test_support.run_suite(suite) File "D:\apps\Python23\lib\test\test_support.py", line 217, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details D:\apps\Python23>python D:\apps\Python23\Lib\test\test_unicode_file.py File doesn't exist (encoded string) after creating it Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_unicode_file.py", line 37, in ? if os.stat(TESTFN_ENCODED) != os.stat(TESTFN_UNICODE): OSError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:55 Message: Logged In: YES user_id=33168 Miki, are you still having this problem with 2.3b1? Can this be closed? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2003-04-26 13:14 Message: Logged In: YES user_id=129426 Both tests run fine on my windows XP box with Python 2.3b... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-24 23:03 Message: Logged In: YES user_id=31435 I personally tested these before the releases, on Win98SE and on Win2000 Pro. No problems there, although test_unicode_file turns itself off on Win9x. I don't have access to an NT box, and these won't get fixed until a Python developer who does have NT can dig into them there. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-03-24 02:51 Message: Logged In: YES user_id=358087 Yes. Version is: 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC v.1200 32 bit (Intel)] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 15:40 Message: Logged In: YES user_id=33168 Is this problem still happening with 2.3a2+ ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470 From noreply@sourceforge.net Thu May 22 23:04:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:04:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-594998 ] test_nis test fails on TRU64 5.1 Message-ID: <E19IyAl-00037S-00@sc8-sf-web3.sourceforge.net> Bugs item #594998, was opened at 2002-08-14 06:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470 Category: Build Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Patrick Finnerty (finnertyp) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_nis test fails on TRU64 5.1 Initial Comment: Platform: TRU64 v5.1a Ran configure with --with-dec-threads options. Also used --without-gcc although this has no impact on test failure. The ouput from ./python ./Lib/test/test_nis.py is large so I've included it in an attached file rather than pasted here. The machine that Python is being built on is a NIS server as well as client. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 18:04 Message: Logged In: YES user_id=33168 I believe this has been fixed. If not, please open a new bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 17:14 Message: Logged In: YES user_id=33168 Patrick, are you able to test if this has been fixed? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-14 20:49 Message: Logged In: YES user_id=33168 I fixed a similar problem on Nov 4. Can you test the latest CVS versions from the head or for 2.2.2+? ---------------------------------------------------------------------- Comment By: Patrick Finnerty (finnertyp) Date: 2002-08-15 09:06 Message: Logged In: YES user_id=594846 On TRU64 this is doucmented as foreach(instatus, inkey, inkeylen, inval, invallen, indata); int instatus; char *inkey; int inkeylen; char *inval; int invallen; char *indata; ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-15 07:05 Message: Logged In: YES user_id=21627 This sounds like some serious memory corruption is going on. Unfortunately, I can't spot a problem, so somebody with access to such a system would need to debug it. My first guess is that the type of the callback function is incorrect. Can you please find out what signatures are involved in yp_all(3)? On Solaris, the callback signature is not declared in a header, but only documented in yp_clnt(3NSL), as foreach(int instatus, char *inkey, int inkeylen, char *inval, int invallen, char *indata); ---------------------------------------------------------------------- Comment By: Patrick Finnerty (finnertyp) Date: 2002-08-15 06:02 Message: Logged In: YES user_id=594846 Uploading the output file from ./python ./Lib/test/test_nis.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-15 05:01 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470 From noreply@sourceforge.net Thu May 22 22:58:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:58:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-651701 ] Bozo getstate w/ slots overrides base Message-ID: <E19Iy4Z-00077u-00@sc8-sf-web4.sourceforge.net> Bugs item #651701, was opened at 2002-12-10 18:10 Message generated for change (Comment added) made by nnorwitz 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: Neal Norwitz (nnorwitz) Date: 2003-05-22 17: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@sourceforge.net Fri May 23 05:47:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 21:47:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-697985 ] Move gmtime function from calendar to time module Message-ID: <E19J4Sf-0002F2-00@sc8-sf-web1.sourceforge.net> Bugs item #697985, was opened at 2003-03-05 08:40 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Move gmtime function from calendar to time module Initial Comment: The gmtime function in the calendar module would be much more logical to have in the time module, since it manipulates tm tuples and unix timestamps, which the other functions in time do, but no other functions in calendar. Related to bug #697983 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-23 00:47 Message: Logged In: YES user_id=31435 I expect the OP meant the calendar.timegm() function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:46 Message: Logged In: YES user_id=33168 The gmtime function is in time, not calendar. Did you mean the opposite that you believe gmtime should be in calendar? gmtime comes from the C version which is the purpose of time, to expose C functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 From noreply@sourceforge.net Thu May 22 23:05:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:05:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-592161 ] installation errors Message-ID: <E19IyC6-00034I-00@sc8-sf-web2.sourceforge.net> Bugs item #592161, was opened at 2002-08-07 12:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470 Category: Distutils Group: Python 2.2.1 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Alicia C. Hopkins (aliciahopkins) Assigned to: Nobody/Anonymous (nobody) Summary: installation errors Initial Comment: with the use of python2 setup.py install, I get the following errors File "setup.py", line 30, in ? packages = ['distutils', 'distutils.command'], File "distutils/core.py", line 101, in setup _setup_distribution = dist = klass(attrs) File "distutils/dist.py", line 130, in __init__ setattr(self, method_name, getattr(self.metadata, method_name)) AttributeError: DistributionMetadata instance has no attribute 'get___doc__' HELP! Alicia Hopkins ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 18:05 Message: Logged In: YES user_id=33168 This problem cannot be reproduced and there is no further input; therefore, I'm closing this report. If you have a problem, please re-open a new bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 16:10 Message: Logged In: YES user_id=33168 Do you still have this problem with Distutils-1.0.3? That is the version in Python 2.2.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-08 11:02 Message: Logged In: NO The setup.py is in the main directory Distutils-1.0.2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-08 04:45 Message: Logged In: YES user_id=6656 Which setup.py is that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470 From noreply@sourceforge.net Thu May 22 22:51:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:51:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-678217 ] test_logging fails Message-ID: <E19IxyC-0006tt-00@sc8-sf-web4.sourceforge.net> Bugs item #678217, was opened at 2003-01-31 11:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 Category: Python Library Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Jeremy Hylton (jhylton) Summary: test_logging fails Initial Comment: When I run the test suite, test_logging sometimes fails. It misses the following output and gets a bunch of exceptions llike the one I included at the end. I haven't counted, but I'd guess that there's one traceback for each missing line of output. test test_logging produced unexpected output: ********************************************************************** *** lines 489-514 of expected output missing: - ERR -> CRITICAL: Message 0 (via logrecv.tcp.ERR) - ERR -> ERROR: Message 1 (via logrecv.tcp.ERR) - INF -> CRITICAL: Message 2 (via logrecv.tcp.INF) - INF -> ERROR: Message 3 (via logrecv.tcp.INF) - INF -> WARN: Message 4 (via logrecv.tcp.INF) - INF -> INFO: Message 5 (via logrecv.tcp.INF) - INF.UNDEF -> CRITICAL: Message 6 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> ERROR: Message 7 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> WARN: Message 8 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> INFO: Message 9 (via logrecv.tcp.INF.UNDEF) - INF.ERR -> CRITICAL: Message 10 (via logrecv.tcp.INF.ERR) - INF.ERR -> ERROR: Message 11 (via logrecv.tcp.INF.ERR) - INF.ERR.UNDEF -> CRITICAL: Message 12 (via logrecv.tcp.INF.ERR.UNDEF) - INF.ERR.UNDEF -> ERROR: Message 13 (via logrecv.tcp.INF.ERR.UNDEF) - DEB -> CRITICAL: Message 14 (via logrecv.tcp.DEB) - DEB -> ERROR: Message 15 (via logrecv.tcp.DEB) - DEB -> WARN: Message 16 (via logrecv.tcp.DEB) - DEB -> INFO: Message 17 (via logrecv.tcp.DEB) - DEB -> DEBUG: Message 18 (via logrecv.tcp.DEB) - UNDEF -> CRITICAL: Message 19 (via logrecv.tcp.UNDEF) - UNDEF -> ERROR: Message 20 (via logrecv.tcp.UNDEF) - UNDEF -> WARN: Message 21 (via logrecv.tcp.UNDEF) - UNDEF -> INFO: Message 22 (via logrecv.tcp.UNDEF) - INF.BADPARENT.UNDEF -> CRITICAL: Message 23 (via logrecv.tcp.INF.BADPARENT.UNDEF) - INF.BADPARENT -> CRITICAL: Message 24 (via logrecv.tcp.INF.BADPARENT) - INF -> INFO: Messages should bear numbers 0 through 24. (via logrecv.tcp.INF) ********************************************************************** Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:51 Message: Logged In: YES user_id=33168 Jeremy, do you still have this problem? I think all the test logging problems have been fixed now. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-29 17:45 Message: Logged In: YES user_id=45365 On MacOS9 the problem is indeed fixed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-25 10:35 Message: Logged In: YES user_id=33168 This problem should be fixed, please test. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 05:40 Message: Logged In: YES user_id=45365 I see this problem on MacPython-OS9 too, occasionally. So if it is closed I would like to hear the resolution, please... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 21:02 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 From noreply@sourceforge.net Thu May 22 22:15:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:15:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-737947 ] Failed assert in stringobject.c Message-ID: <E19IxPh-0000fk-00@sc8-sf-web2.sourceforge.net> Bugs item #737947, was opened at 2003-05-14 18:51 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 7 Submitted By: Fernando Pérez (fer_perez) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Failed assert in stringobject.c Initial Comment: Here's how to reproduce the problem: [~]> cat test.py import readline readline.get_completer_delims() [~]> echo 'execfile("test.py");print 10' | python python: Objects/stringobject.c:111: PyString_FromString: Assertion `str !=((void *)0)' failed. Abort This was tested with 2.2.1 under RedHat 8.0. On c.l.py, a Mandrake 9.0 (py2.2.2) user reported a segfault with the same. Martin reported not seeing the problem with 2.3b1. However, others suggested still filing it for a possible backport, and also in case the fix was accidental. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:14 Message: Logged In: YES user_id=33168 Barry, should this be handled for 2.2.3? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-14 22:28 Message: Logged In: YES user_id=33168 revision 2.54 in Modules/readline.c fixed this problem. Patch #512981: Update readline input stream on sys.stdin/out change. The patch must be modified for 2.2.3 because there is an API change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 From noreply@sourceforge.net Thu May 22 22:52:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:52:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: <E19IxzH-0002X0-00@sc8-sf-web3.sourceforge.net> Bugs item #669838, was opened at 2003-01-17 12:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec <visit_decref>, arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "<string>", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "<string>", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "<string>", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:52 Message: Logged In: YES user_id=33168 Gregory, do you still have this problem? Do you believe there is a bug or can we close this report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-24 16:01 Message: Logged In: YES user_id=33168 After running configure, you must remove all the modules and rebuild them too. This doesn't happen by default. You can also do rm build/*/*.o build/*/*.so to remove the modules. make clean should also work. Have you tried running valgrind, purify, electric fence, or some other memory checker on the code. Perhaps there is a memory problem in the pyagrep module? ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-24 15:46 Message: Logged In: YES user_id=222034 It is hard to reproduce... I realized that the bug may be in a module I use called AGREPY downloadable from http://www.bio.cam.ac.uk/~mw263/pyagrep.html. I tried to reproduce my Python 2.2.2 install with "./configure --with- pydebug" as suggested, but then I get the following error: /usr/greg/soft/linux/python/Python-2.2.2/python rules.py Adding parser accelerators ... Done. Traceback (most recent call last): File "rules.py", line 39, in ? import string, os, agrepy ImportError: /usr/greg/soft/linux/python/Python- 2.2.2/build/lib.linux-i686-2.2/agrepy.so: undefined symbol: Py_InitModule4 [6589 refs] I was mistaken to suspect my use of the "exec" statement, which I replaced with "eval" and the problem still happened. It is not easy to come up with a reasonably small piece of code reproducing the problem! gregory ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-17 13:43 Message: Logged In: YES user_id=33168 Can you post any code which causes the crash, even if it only crashes sometimes? Can you build python with ./configure --with-pydebug and run your program? This may find the problem closer to the cause. ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-17 12:05 Message: Logged In: YES user_id=222034 I forgot to mention that this program is using the "exec()" builtin heavily, and I believe that the crash is related to this. gregory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Thu May 22 22:48:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 14:48:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i Message-ID: <E19IxvV-00043J-00@sc8-sf-web1.sourceforge.net> Bugs item #694431, was opened at 2003-02-27 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=694431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.3a2 Build fails on HP-UX11i Initial Comment: While building Python 2.3a2 on HP-UX11i I got the following error: ld -b build/temp.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.o -L/opt/python/lib - L/usr/local/lib -o build/lib.hp-ux-B.11.11- 9000/785-2.3/_iconv_codec.sl /usr/lib/dld.sl: Unresolved symbol: libiconv_open (code) from build/lib.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.sl sh[3]: 25624 Abort(coredump) *** Error exit code 134 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:48 Message: Logged In: YES user_id=33168 Richard, is this still a problem? iconv has been removed. Should this bug be closed? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-31 02:36 Message: Logged In: YES user_id=200117 Yes, I was just trying to get Python to compile. I'm not aware that we have any need for the iconv codec module. What is the best way to get the build process to omit it from the build? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:55 Message: Logged In: YES user_id=33168 This means the iconv_open() call is failing. Unless you know you need this module, you probably don't. And if you do need this module, you probably know more than I do. :-) So if you are just trying to get this working, I don't think it's a big deal. It seems to work on some HPUX machines. I suspect the reason the iconv_open() is failing is because of a configuration on your machine. This call is for translating character sets. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-26 11:26 Message: Logged In: YES user_id=200117 Hi Neal, I edited Modules/Setup line 483 like this: _iconv_codec _iconv_codec.c -I/usr/include I can now build Python! However test_iconv_codecs fails: capulet:dist/src > ./python ./Lib/test/test_iconv_codecs.py Traceback (most recent call last): File "./Lib/test/test_iconv_codecs.py", line 3, in ? import codecs, _iconv_codec RuntimeError: can't initialize the _iconv_codec module: iconv_open() failed I tried adding '-l:libdld.sl' to line 483 (as suggested by the man page) but the test still fails. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-26 09:43 Message: Logged In: YES user_id=200117 Hi Neal, I have now discovered that there is a different version of iconv.h on my workstation in /usr/local/include. It appears to be part of the zlib package and it contains the pre-processor macros which are converting the iconv statements to libiconv. It is being used instead of the one in /usr/include, because the compile command contains -I/usr/local/include Is there any easy to prevent this path from being added to the compile commands? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-25 12:51 Message: Logged In: YES user_id=200117 Neal, The original error referred to unresolved symbol 'libiconv_open'. The source module _iconv_codec.c contains calls to iconv_open(), not libiconv_open(). However, if I recompile it with the -E flag there is a pre- processor substitution happening which is converting all instances of 'iconv' to 'libiconv' Here I grepped the pre-processor output for 'iconv'... extern int _libiconv_version; typedef void* libiconv_t ; extern libiconv_t libiconv_open (const char* tocode, const char* fromcode); extern size_t libiconv (libiconv_t cd, char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); extern int libiconv_close (libiconv_t cd); extern int libiconvctl (libiconv_t cd, int request, void* argument); libiconv_t enchdl, dechdl; if (libiconv (self->enchdl, (char**)&inp, &inplen, &out, &outlen) size_t res = libiconv (self->dechdl, (char**)&inp, &inplen, &out, &outlen); new->enchdl = new->dechdl = (libiconv_t )(-1); new->dechdl = libiconv_open ("ucs-2-internal" , new->encoding); if (new->dechdl == (libiconv_t )(-1)) { new->enchdl = libiconv_open (new->encoding, "ucs- 2-internal" ); if (new->enchdl == (libiconv_t )(-1)) { libiconv_close (new->dechdl); new->dechdl = (libiconv_t )(-1); if (self->enchdl != (libiconv_t )-1) libiconv_close (self->enchdl); if (self->dechdl != (libiconv_t )-1) libiconv_close (self->dechdl); libiconv_t hdl = libiconv_open ("ucs-2- internal" , "ISO-8859-1"); if (hdl == (libiconv_t )-1) { res = libiconv (hdl, &inptr, &insize, &outptr, &outsize); libiconv_close (hdl); libiconv_close (hdl); Is this supposed to be happening?? If not, what could be causing it?? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:52 Message: Logged In: YES user_id=33168 Looking further into the python configure, I see that the option is --with-dl-dld, however, this option is not supported. Can try to play with the build options to find the magic that works on your version of HPUX? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:48 Message: Logged In: YES user_id=33168 Richard, in the manpage it says that iconv has a dependancy on libdld.sl. Perhaps you need to configure python --with-dld. Can you try that? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-04 12:09 Message: Logged In: YES user_id=200117 Neal, I will try to help, but internet access is difficult at work so responses may not be prompt. I had a look at the man page but it was not clear to me which library contains iconv_open. I will attach text copy of the man page for you. I also include some nm output from libc.sl which refers to iconv_open, but I'm not sure if it means that it contains the code for the function. Let me know if I can try anything else. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:15 Message: Logged In: YES user_id=33168 Richard, can you help diagnose further since I can't reproduce on HP-UX 11.00? My initial guess is that iconv_open is in a different location, therefore the linking is faililng. Does man iconv_open reveal what library iconv_open is in? To add directories, etc. to the build/link of iconv, you will need to edit setup.py (or test on the command line). Check around line 620 in setup.py. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-03 04:14 Message: Logged In: YES user_id=200117 Sorry for the delay but I had to download from CVS at home yesterday (Sunday 2nd) and build on HP-UX at work today. Unfortunately I'm still getting the same linker error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 12:37 Message: Logged In: YES user_id=33168 This iconv_codec problem may be fixed. Please test with current CVS to verify. See SF bug #690012. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-27 22:45 Message: Logged In: YES user_id=33168 Richard, can you try the latest version from CVS. I don't have this problem on hp-ux-B.11.00-9000/829 I do have a problem with readline, but I think that's specific to the machine I'm building on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 From noreply@sourceforge.net Thu May 22 23:09:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:09:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-651701 ] Bozo getstate w/ slots overrides base Message-ID: <E19IyFU-0007Yc-00@sc8-sf-web4.sourceforge.net> Bugs item #651701, was opened at 2002-12-10 17:10 Message generated for change (Comment added) made by pafein 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: Peter Fein (pafein) Date: 2003-05-22 17: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 16: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@sourceforge.net Thu May 22 23:09:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 22 May 2003 15:09:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-456398 ] strange IRIX test_re/test_sre failure Message-ID: <E19IyFz-0007ZE-00@sc8-sf-web4.sourceforge.net> Bugs item #456398, was opened at 2001-08-29 00:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=456398&group_id=5470 Category: Regular Expressions Group: Platform-specific Status: Open Resolution: None Priority: 4 Submitted By: Andrew Dalke (dalke) Assigned to: Fredrik Lundh (effbot) Summary: strange IRIX test_re/test_sre failure Initial Comment: The test_re and test_sre regression tests cause a core dump with the CVS version of Python. If I run the file directly I don't get the core dump. test_pyclbr test_pyexpat test test_pyexpat skipped -- No module named pyexpat test_quopri test_re make: *** [test] Segmentation fault (core dumped) ./python -E -tt ./Lib/test/regrtest.py -l ^C % % ./python -E -tt ./Lib/test/test_re.py Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite % This is under an IRIX 6.4 machine, which is several years old. Python is compiled with gcc 2.95.2 but using the vendor's assembler. The assembler is also out of date. There were known problems with in 1.5.2 where the optimizer broke the pcre module. So I recompiled _sre.c with "-g". That did not fix the problem. Here's the stack trace from the core file. > 0 mark_save(state = <no such address>, lo = <no such address>, hi = <no such ad dress>) ["/usr2/people/dalke/cvses/python/dist/src/./Modules/_s re.c":280, 0x100a1e 2c] 1 sre_match(state = 0x7fff1200, pattern = 0x104ec55a, level = 1357) ["/usr2/peo ple/dalke/cvses/python/dist/src/Modules/_sre.c":1053, 0x100a44b4] 2 sre_match(state = 0x7fff1200, pattern = 0x104ec55a, level = 1356) ["/usr2/peo ple/dalke/cvses/python/dist/src/Modules/_sre.c":1057, 0x100a4504] Guessing it's in the "recursion limit" test. I don't know if the problem is in _sre.c or in the IRIX libraries. I don't have access to a newer version of IRIX. I tried to force the core dump to occur without having to go through the whole regression suite. That doesn't work, which is itself suspecious. % ./python -E -tt ./Lib/test/regrtest.py -l test_re test_re 1 test OK. % ./python -E -tt ./Lib/test/regrtest.py -l test_array test_re test_array test_re All 2 tests OK. % ./python -E -tt ./Lib/test/regrtest.py -l test_array test_re test_re test_array test_re test_re All 3 tests OK. % I get the same failures with test_sre. Andrew dalke@dalkescientific.com ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 18:09 Message: Logged In: YES user_id=33168 Closing this report at the test pass for me on IRIX 6.5 and there's no further input. If a bug persists, please open a new report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:40 Message: Logged In: YES user_id=33168 Andrew, is this still a problem? How big is the stack? Could the problem have been that the max stack size was exceeded which caused the crash? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=456398&group_id=5470 From noreply@sourceforge.net Fri May 23 09:44:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 01:44:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-741806 ] test_long failure Message-ID: <E19J8A1-000812-00@sc8-sf-web2.sourceforge.net> Bugs item #741806, was opened at 2003-05-22 17:32 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test_long failure Initial Comment: $ python Lib/test/test_long.pyc long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow Traceback (most recent call last): File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 442, in ? test_float_overflow() File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 394, in test_float_overflow eval(test, namespace) File "<string>", line 0, in ? ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 $ This happens on Tru64Unix 5.1A, cc/cxx compiled binaries. ---------------------------------------------------------------------- >Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-23 10:44 Message: Logged In: YES user_id=696559 Hmm, I see tthe patch in list of patches, but how to download it? :( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 23:08 Message: Logged In: YES user_id=33168 Patch 719359 should fix this problem. Can you test this patch? ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 17:54 Message: Logged In: YES user_id=696559 ${ac_dA}SIZEOF_LONG${ac_dB}SIZEOF_LONG${ac_dC}8${ac_dD} ${ac_dA}HAVE_LONG_LONG${ac_dB}HAVE_LONG_LONG${ac_dC}1${ac_dD} ${ac_dA}SIZEOF_LONG_LONG${ac_dB}SIZEOF_LONG_LONG${ac_dC}8${ac_dD} ${ac_uA}SIZEOF_LONG${ac_uB}SIZEOF_LONG${ac_uC}8${ac_uD} ${ac_uA}HAVE_LONG_LONG${ac_uB}HAVE_LONG_LONG${ac_uC}1${ac_uD} ${ac_uA}SIZEOF_LONG_LONG${ac_uB}SIZEOF_LONG_LONG${ac_uC}8${ac_uD} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 From noreply@sourceforge.net Fri May 23 11:08:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 03:08:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19J9T2-0005P3-00@sc8-sf-web1.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 21:49 Message generated for change (Comment added) made by anze You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Anze Slosar (anze) Date: 2003-05-23 10:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 21:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 17:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 12:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 11:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 22:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Fri May 23 14:21:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 06:21:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: <E19JCUU-0005lj-00@sc8-sf-web1.sourceforge.net> Bugs item #737202, was opened at 2003-05-13 19:54 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- >Comment By: Hartmut Goebel (htgoebel) Date: 2003-05-23 15:21 Message: Logged In: YES user_id=376953 I rethought this: The reason for this type of split is to make it possible to pass parameters as part of the URL, like Zope does. So the snippet above should be changed to something like this: i = 0 while 1: # get the next path-element out of the url i = rest.find('/', i) if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translatepath(scriptname) if os.isdir(scriptname): # if scriptname is a directory, continue "walking" the url continue # scriptname is not a directory, stop "walking" the url break Patch is included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply@sourceforge.net Fri May 23 15:00:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 07:00:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: <E19JD6O-00053u-00@sc8-sf-web3.sourceforge.net> Bugs item #729317, was opened at 2003-04-29 05:41 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Larry Bugbee (thunderbug) Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a <type 'float'> and _tkinter.TCL_VERSION is a <type 'str'> Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-23 16:00 Message: Logged In: YES user_id=45365 I'm getting fed up with this bug. I uninstalled the Batteries Included distribution and installed the minimal TclTkAqua and indeed: everything worked as expected. Then I installed BI again, expecting the problem to come back, *but it didn't*. Then I asked other people on the PythonMac-SIG to do the same: for everyone the problem disappeared with the minimal install, for some it came back with the BI install, for some it didn't. I suggest we add the str() calls around the test of tcl_version and leave it at that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-19 21:48 Message: Logged In: YES user_id=21627 On incrTcl: I still cannot reproduce that. On Linux, incrTcl is typically installed, but it comes as a Tcl package. So it won't get loaded until somebody does 'package require Itcl'. On loading that package, I see no change in type of tcl_version. Grepping the source of Itcl 3.2.1, I find no occurrence of tcl_version. What specific file contains what specific access to tcl_version on your system? On using internal APIs: I see, using GetDoubleFromObj is probably better. However, it won't change the behaviour at all: Python accesses the double representation only if it already knows the Tcl object is a double. In that case, Tcl_GetDoubleFromObj does exactly the same thing that _tkinter already does. On the importance of #518625: It is important for the following reasons: a) it allows to round-trip doubles without loss of precision. That fixes #721171. b) it improves type safety, by returning the proper object types for widget attributes. c) it improves efficiency, but not requiring expensive string-object conversions. It also provides full backwards compatibility, by allowing applications to set Tkinter.wantobjects=False. I'll try to come up with a fix for this bug, although I would really prefer if I could reproduce it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-19 15:25 Message: Logged In: YES user_id=45365 I did some more investigating, and it turns out that Jim and Benjamin's analysis of the problem is correct. The distribution that most people install for MacOSX is a "batteries included" distribution of Tcl/Tk, which includes lots of optional packages that initialize themselves. Some of these initializations do a compare of tcl_version to the numeric value 8.3 or so, thereby coercing tcl_version to a float. I removed all traces of tcl/tk from my machine and installed a minimal tcl/tk and the problem does not occur. On Linux everyone apparently installs a bare tcl/tk, but once you install incrTcl or whatever yourself you will run into the same problem. As to your (Martin's) statement that _tkinter uses only official Tcl APIs: the TCL folks disagree with this. The official way to get a float from a tcl object is using Tcl_GetDoubleFromObj(), not looking at the cached internal value. A tcl object is a string, and that's all there is. Anything else is optimization. The question now is really: how important is patch #518625. It apparently breaks Tcl object semantics, is the added convenience worth it. If it is then we simply add str() calls around the comparison of tcl_version in Tkinter, but then we should remember that this same problem will show up in different guises later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-19 07:28 Message: Logged In: YES user_id=21627 I disagree that patch #518625 is in error; _tkinter uses only official Tcl API to access Tcl objects. It is certainly the case that a computation with tcl_version may cause it to change its type from string. However, I would still like to find out where exactly that happens on the Mac, as it happens nowhere else, and Tkinter most certainly does not use any Tcl code that may trigger such a change. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-18 23:22 Message: Logged In: YES user_id=45365 Martin, I'm assigning back to you, because I'm out of my water here. I discussed this problem with the MacTcl people, and it seems that what was checked in in _tkinter.c for patch 518625 is not correct: if something is initialized as a string in Tcl and then some code accesses it as a float the internal float representation will be created automatically. In other words: the FromObj() code attempts to graft Python semantics on Tcl objects, which is prone to obscure errors. Here are some excerpts from relevant mail messages: ------------- >From Jim Ingham: tcl_version is created as a string variable with the value "8.2". If somebody tried to do some math with it (like evaluate expr $tcl_version <= 8.4 or something) then Tcl would set the internal representation to a float. I don't see any place where we are doing that, but maybe your Tkinter code does that to check something on Mac OS X? Anyway that would not be an error on Tcl's part. If you want tcl_version in Python explicitly as a string, you need to make sure the string representation exists, and then get the variable as a string. You can't rely on their being or not being any particular internal representation. ------------------ And from Benjamin Riefenstahl: Well, somebody may already have told you that, but that's not how Tcl works. In Tcl *all* values are strings. You use Tcl_GetStringFromObj() to get that value. That's it. If you want a floating point, you explicitly *convert* by using Tcl_GetDoubleFromObj(). Everything you see related to "types" is just internal speed optimizations to avoid double conversions. These internal representations come and go at the whim of the implementation. Accessing these infos without the official APIs will lead to errors and inconsistent behaviour, as you have seen. The details of the behaviour will also quite likely change from Tcl version to Tcl version. --------------- ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:29 Message: Logged In: YES user_id=21627 This seems to happen only in the Mac version of Tcl. I can't reproduce it on Linux or Windows, and I can't see anything in the Tcl sources that may causing it. tcl_version is set in generic/tclBasic.c using Tcl_SetVar, i.e. as a string. It is never referred-to in the Tcl sources, except for being returned from 'info tclversion'. So I can't see why it would ever be changed to a floating point object. Perhaps the Mac is not using the original Tcl source code? Assigning to Jack for further investigation. ---------------------------------------------------------------------- Comment By: Larry Bugbee (thunderbug) Date: 2003-05-10 04:44 Message: Logged In: YES user_id=10953 Several of us have encountered this. Personally, I have seen this with Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2. ...and with Tcl/Tk 8.4.2. ...and under 10.2.5 and 2.3b1. I've tried several combinations. My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/ python/mac/ . I hope this helps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 00:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 07:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Fri May 23 15:03:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 07:03:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-742342 ] Python crashes if recursively reloading modules Message-ID: <E19JD8y-0005c9-00@sc8-sf-web2.sourceforge.net> Bugs item #742342, was opened at 2003-05-23 14: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=742342&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Eder (chris_ce) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes if recursively reloading modules Initial Comment: If one tries to recursively reload modules, python crashes with a segfault. e.g. if the file "foo.py" looks something like: import foo reload (foo) .... the python interpreter crashes when reading this file. I have been able to reproduce the problem both with python2.2 and python2.3 under linux. Although recursive reloads are faulty code, this should lead to an exception but not to a segfault of the interpreter. In our case, this bug allows a faulty user script to crash our program. Sorry if this is already a known bug, but I searched in Sorceforge (and also in Google) and did not find something similar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 From noreply@sourceforge.net Fri May 23 15:04:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 07:04:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-571343 ] Mixing framework and static Pythons Message-ID: <E19JDAD-0005Fu-00@sc8-sf-web3.sourceforge.net> Bugs item #571343, was opened at 2002-06-19 23:49 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571343&group_id=5470 Category: Macintosh Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Mixing framework and static Pythons Initial Comment: We need to check that (on OS X) the error message you get when you attempt to load an extension module in the "wrong" Python (i.e. an extension module built for a static Python into a framework python or vice versa) is of a form understandable to naive users, and not of the "undefined external: foobar" variety. As the situation of having both Pythons on your system may well become commonplace this needs to be addressed in 2.2.X too. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-23 16:04 Message: Logged In: YES user_id=45365 It turns out 2.2.3 gives the correct error message "(Fatal Python error: Interpreter not initialized (version mismatch?)" when importing a 2.3 framework-Python module. Theoretically it may give the wrong error message when importing a 2.2.3 framework-Python module, but I don't think many people will build 2.2.3 framework builds, as they have little extra to offer over the non-framework builds. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 16:16 Message: Logged In: YES user_id=45365 In Python 2.3 this doesn't seem to be a problem, you always get an error message on import if there is a problem. In 2.2 it is a problem, which can be repeated as follows: - Build and install a framework 2.2.X - Add /Library/Framework/Python.framework/..../lib/python2.2 and .../lib-dynload to sys.path (at the beginning) - run /usr/bin/python (version 2.2) - run import test.regrtest; test.regrtest.main() - witness weird errors culminating in a crash. The reverse (loading non-framework modules into a framework 2.2 python) seems to work okay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571343&group_id=5470 From noreply@sourceforge.net Fri May 23 15:11:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 07:11:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-740424 ] MacPython-OS9 distutils breaks on OSX Message-ID: <E19JDGU-0004qf-00@sc8-sf-web4.sourceforge.net> Bugs item #740424, was opened at 2003-05-20 14:38 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&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-OS9 distutils breaks on OSX Initial Comment: MacPython-OS9 distutils (or actually the underlying mkcwproject package) does not always work on OSX. The problem is that references to the GUSI source tree are relative pathnames to the Python sourcetree with :: in them, and CW (at least CW7) doesn't understand this when running on OSX. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-23 16:11 Message: Logged In: YES user_id=45365 Just: do you mean that *no* distutils-based packages build correctly with MacPython-OS9 on OSX with CW8 because of the incorrect pathnames? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-20 18:18 Message: Logged In: YES user_id=92689 I've observed that (at least with CW8) _all_ pathnames are wrong: they do use /, but the paths are constructed as if they are OS9 paths, ie. the start with the volume name ( /MyHD/rest/of/path ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&group_id=5470 From noreply@sourceforge.net Fri May 23 15:31:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 07:31:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-740424 ] MacPython-OS9 distutils breaks on OSX Message-ID: <E19JDa5-0006dX-00@sc8-sf-web3.sourceforge.net> Bugs item #740424, was opened at 2003-05-20 14:38 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&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-OS9 distutils breaks on OSX Initial Comment: MacPython-OS9 distutils (or actually the underlying mkcwproject package) does not always work on OSX. The problem is that references to the GUSI source tree are relative pathnames to the Python sourcetree with :: in them, and CW (at least CW7) doesn't understand this when running on OSX. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-05-23 16:31 Message: Logged In: YES user_id=92689 I didn't do a _lot_ of testing, but it sure looked like it simply doesn't work at all. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-23 16:11 Message: Logged In: YES user_id=45365 Just: do you mean that *no* distutils-based packages build correctly with MacPython-OS9 on OSX with CW8 because of the incorrect pathnames? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-05-20 18:18 Message: Logged In: YES user_id=92689 I've observed that (at least with CW8) _all_ pathnames are wrong: they do use /, but the paths are constructed as if they are OS9 paths, ie. the start with the volume name ( /MyHD/rest/of/path ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&group_id=5470 From noreply@sourceforge.net Fri May 23 15:41:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 07:41:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-735274 ] FILEMODE not honoured Message-ID: <E19JDjl-0007Be-00@sc8-sf-web3.sourceforge.net> Bugs item #735274, was opened at 2003-05-09 17:07 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735274&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: FILEMODE not honoured Initial Comment: The Python build process doesn't honour the FILEMODE setting in Makefile.pre.in (or passed in at install time with "make FILEMODE=664 install") because configure sets the install command to an explicit "${INSTALL} -m 644" in stead of to "${INSTALL} -m ${FILEMODE}". DIRMODE and EXEMODE are handled correctly. Please let me know whether you agree and assign back to me, if you agree I'll put the changes in. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-23 16:41 Message: Logged In: YES user_id=45365 Hmm. It turns out that our configure.in isn't responsible for what gets set in the INSTALL_DATA and related variables: this is done by autoconf through the AC_PROG_INSTALL macro. I guess this means that fixing it is difficult, so let's forget about it. I'll continue doing the "chmod -R g+w" over the tree as I do now. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-11 22:40 Message: Logged In: YES user_id=21627 I'm probably missing something: Where precisely is EXEMODE being used? As for FILEMODE: Is it important that this is honored? Users wanting to override this can also override INSTALL_DATA instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735274&group_id=5470 From noreply@sourceforge.net Fri May 23 16:55:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 08:55:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-678217 ] test_logging fails Message-ID: <E19JEt0-00060X-00@sc8-sf-web1.sourceforge.net> Bugs item #678217, was opened at 2003-01-31 16:43 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: test_logging fails Initial Comment: When I run the test suite, test_logging sometimes fails. It misses the following output and gets a bunch of exceptions llike the one I included at the end. I haven't counted, but I'd guess that there's one traceback for each missing line of output. test test_logging produced unexpected output: ********************************************************************** *** lines 489-514 of expected output missing: - ERR -> CRITICAL: Message 0 (via logrecv.tcp.ERR) - ERR -> ERROR: Message 1 (via logrecv.tcp.ERR) - INF -> CRITICAL: Message 2 (via logrecv.tcp.INF) - INF -> ERROR: Message 3 (via logrecv.tcp.INF) - INF -> WARN: Message 4 (via logrecv.tcp.INF) - INF -> INFO: Message 5 (via logrecv.tcp.INF) - INF.UNDEF -> CRITICAL: Message 6 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> ERROR: Message 7 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> WARN: Message 8 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> INFO: Message 9 (via logrecv.tcp.INF.UNDEF) - INF.ERR -> CRITICAL: Message 10 (via logrecv.tcp.INF.ERR) - INF.ERR -> ERROR: Message 11 (via logrecv.tcp.INF.ERR) - INF.ERR.UNDEF -> CRITICAL: Message 12 (via logrecv.tcp.INF.ERR.UNDEF) - INF.ERR.UNDEF -> ERROR: Message 13 (via logrecv.tcp.INF.ERR.UNDEF) - DEB -> CRITICAL: Message 14 (via logrecv.tcp.DEB) - DEB -> ERROR: Message 15 (via logrecv.tcp.DEB) - DEB -> WARN: Message 16 (via logrecv.tcp.DEB) - DEB -> INFO: Message 17 (via logrecv.tcp.DEB) - DEB -> DEBUG: Message 18 (via logrecv.tcp.DEB) - UNDEF -> CRITICAL: Message 19 (via logrecv.tcp.UNDEF) - UNDEF -> ERROR: Message 20 (via logrecv.tcp.UNDEF) - UNDEF -> WARN: Message 21 (via logrecv.tcp.UNDEF) - UNDEF -> INFO: Message 22 (via logrecv.tcp.UNDEF) - INF.BADPARENT.UNDEF -> CRITICAL: Message 23 (via logrecv.tcp.INF.BADPARENT.UNDEF) - INF.BADPARENT -> CRITICAL: Message 24 (via logrecv.tcp.INF.BADPARENT) - INF -> INFO: Messages should bear numbers 0 through 24. (via logrecv.tcp.INF) ********************************************************************** Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-23 15:55 Message: Logged In: YES user_id=31392 I haven't seen the error in a while. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 21:51 Message: Logged In: YES user_id=33168 Jeremy, do you still have this problem? I think all the test logging problems have been fixed now. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-29 21:45 Message: Logged In: YES user_id=45365 On MacOS9 the problem is indeed fixed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-25 14:35 Message: Logged In: YES user_id=33168 This problem should be fixed, please test. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 10:40 Message: Logged In: YES user_id=45365 I see this problem on MacPython-OS9 too, occasionally. So if it is closed I would like to hear the resolution, please... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-01 02:02 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 From noreply@sourceforge.net Fri May 23 17:01:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 09:01:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-742342 ] Python crashes if recursively reloading modules Message-ID: <E19JEyw-0002mQ-00@sc8-sf-web3.sourceforge.net> Bugs item #742342, was opened at 2003-05-23 14:03 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Eder (chris_ce) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes if recursively reloading modules Initial Comment: If one tries to recursively reload modules, python crashes with a segfault. e.g. if the file "foo.py" looks something like: import foo reload (foo) .... the python interpreter crashes when reading this file. I have been able to reproduce the problem both with python2.2 and python2.3 under linux. Although recursive reloads are faulty code, this should lead to an exception but not to a segfault of the interpreter. In our case, this bug allows a faulty user script to crash our program. Sorry if this is already a known bug, but I searched in Sorceforge (and also in Google) and did not find something similar. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-23 16:01 Message: Logged In: YES user_id=31392 I expect this is a platform-specific problem with the Python recursion limit. Can you report two things? The value returned by sys.getrecursionlimit(), and the last limit reported by Misc/find_recursionlimit.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 From noreply@sourceforge.net Fri May 23 17:30:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 09:30:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19JFQu-0002v3-00@sc8-sf-web4.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 16:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-23 12:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 06:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 12:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 07:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 06:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 17:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Fri May 23 19:30:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 11:30:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-742342 ] Python crashes if recursively reloading modules Message-ID: <E19JHJh-0005Gg-00@sc8-sf-web1.sourceforge.net> Bugs item #742342, was opened at 2003-05-23 14:03 Message generated for change (Comment added) made by chris_ce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Eder (chris_ce) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes if recursively reloading modules Initial Comment: If one tries to recursively reload modules, python crashes with a segfault. e.g. if the file "foo.py" looks something like: import foo reload (foo) .... the python interpreter crashes when reading this file. I have been able to reproduce the problem both with python2.2 and python2.3 under linux. Although recursive reloads are faulty code, this should lead to an exception but not to a segfault of the interpreter. In our case, this bug allows a faulty user script to crash our program. Sorry if this is already a known bug, but I searched in Sorceforge (and also in Google) and did not find something similar. ---------------------------------------------------------------------- >Comment By: Christian Eder (chris_ce) Date: 2003-05-23 18:30 Message: Logged In: YES user_id=785436 I tried it on 2 of our development PC's and got the following results on both of them: sys.getrecursionlimit () ===> 1000 python find_recursionlimit.py ===> 2800 Seems a bit strange, doesn't it ? I had expected the sys.recursionlimit to be higher than the actual limit. Anyway, recursive reloads are quite easy to detect, so shouldn't the interpreter detect such statements and raise an appropriate error exception (not resulting in a maximum recursion depth exceeded error) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-23 16:01 Message: Logged In: YES user_id=31392 I expect this is a platform-specific problem with the Python recursion limit. Can you report two things? The value returned by sys.getrecursionlimit(), and the last limit reported by Misc/find_recursionlimit.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 From noreply@sourceforge.net Fri May 23 19:56:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 11:56:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-742342 ] Python crashes if recursively reloading modules Message-ID: <E19JHiq-0002XG-00@sc8-sf-web3.sourceforge.net> Bugs item #742342, was opened at 2003-05-23 10:03 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Eder (chris_ce) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes if recursively reloading modules Initial Comment: If one tries to recursively reload modules, python crashes with a segfault. e.g. if the file "foo.py" looks something like: import foo reload (foo) .... the python interpreter crashes when reading this file. I have been able to reproduce the problem both with python2.2 and python2.3 under linux. Although recursive reloads are faulty code, this should lead to an exception but not to a segfault of the interpreter. In our case, this bug allows a faulty user script to crash our program. Sorry if this is already a known bug, but I searched in Sorceforge (and also in Google) and did not find something similar. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-23 14:56 Message: Logged In: YES user_id=31435 The default recursion limit is unconditionally defined -- it doesn't vary across platforms. If you can submit a patch, that would help. Note that there's nothing wrong with (indirectly) recursive imports in Python (they're delicate but frequently used anyway), so we can't raise an exception on that. ---------------------------------------------------------------------- Comment By: Christian Eder (chris_ce) Date: 2003-05-23 14:30 Message: Logged In: YES user_id=785436 I tried it on 2 of our development PC's and got the following results on both of them: sys.getrecursionlimit () ===> 1000 python find_recursionlimit.py ===> 2800 Seems a bit strange, doesn't it ? I had expected the sys.recursionlimit to be higher than the actual limit. Anyway, recursive reloads are quite easy to detect, so shouldn't the interpreter detect such statements and raise an appropriate error exception (not resulting in a maximum recursion depth exceeded error) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-23 12:01 Message: Logged In: YES user_id=31392 I expect this is a platform-specific problem with the Python recursion limit. Can you report two things? The value returned by sys.getrecursionlimit(), and the last limit reported by Misc/find_recursionlimit.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 From noreply@sourceforge.net Fri May 23 23:46:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 15:46:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-665194 ] datetime-RFC2822 roundtripping Message-ID: <E19JLJL-0003mr-00@sc8-sf-web3.sourceforge.net> Bugs item #665194, was opened at 2003-01-09 10:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-23 15:46 Message: Logged In: YES user_id=357491 time.strptime doesn't solve your problem? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 05:05 Message: Logged In: YES user_id=89016 totimestamp() should be the inverse of fromtimestamp(), i.e. foo.totimestamp() should be the same as time.mktime(foo.timetuple()). datetime.datetime.totimestamp() should raise OverflowError iff time.mktime() raises OverflowError. But as this may lose precision, I'd say it would be better, if datetime supported RFC1123 conversion directly, i.e. two methods frommime() and tomime(), that parse and format strings like "Sun, 06 Nov 1994 08:49:37 GMT" (what rfc822.parsedate() and rfc822.formatdate() do) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 08:32 Message: Logged In: YES user_id=31435 Define what totimestamp() should do. The range of timestamps supported by the *platform* C library (and so indirectly by Python's time module) isn't defined by any standard, and isn't easily discoverable either. It may or may not work before 1970, may or may not after 2038. datetime covers days far outside that range. Note that even a double doesn't have enough bits of precision to cover the full range of datetime values, either. In contrast, ordinals are wholly under Python's control, so we can promise surprise-free conversion in both directions. All we can promise about timestamps is that if the platform supports a timestamp for a time in datetime's range, datetime can make sense of it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-11 04:33 Message: Logged In: YES user_id=89016 OK, I'll mark this a feature request. datetime has fromordinal() and toordinal(), it has fromtimestamp(), so I'd say a totimestamp() method would be a logical addition. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-10 21:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 From noreply@sourceforge.net Fri May 23 23:46:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 15:46:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-723495 ] runtime_library_dirs broken under OS X Message-ID: <E19JLJQ-00051O-00@sc8-sf-web2.sourceforge.net> Bugs item #723495, was opened at 2003-04-18 06:41 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470 Category: Distutils Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: runtime_library_dirs broken under OS X Initial Comment: gcc and ld on OSX don't seem to support the -R option, breaking runtime_library_dirs and any distutils installed extensions that require it. I've only checked Python 2.2.2 so far. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-24 00:46 Message: Logged In: YES user_id=45365 Fixed in unixccompiler rev 1.38.6.2. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-24 15:15 Message: Logged In: YES user_id=45365 Ok, I'll fix if there's a 2.2.3 release upcoming. Thanks for the report! ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-04-24 07:41 Message: Logged In: YES user_id=46639 Yup - that looks like all that is needed to be done. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-18 13:35 Message: Logged In: YES user_id=45365 It looks like backporting the rev. 1.48 fix to Lib/distutils/unixccompiler.py should do the trick. I've attached the patch that should do the trick, if you could try this that would be helpful. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-04-18 13:08 Message: Logged In: YES user_id=46639 Looks like this has been fixed in 2.3a2: if sys.platform[:6] == "darwin": # MacOSX's linker doesn't understand the -R flag at all return "-L" + dir elif compiler[:3] == "gcc" or compiler[:3] == "g++": return "-Wl,-R" + dir else: return "-R" + dir I can't find a bug report or patch on this fix, and I don't know if it is in any 2.2.x branch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-04-18 10:58 Message: Logged In: YES user_id=45365 Could you elaborate a bit on what breaks, and/or give an example that breaks? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723495&group_id=5470 From noreply@sourceforge.net Fri May 23 23:48:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 23 May 2003 15:48:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19JLLC-0003ui-00@sc8-sf-web3.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 21:49 Message generated for change (Comment added) made by anze You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Anze Slosar (anze) Date: 2003-05-23 22:48 Message: Logged In: YES user_id=447507 Of course, it doesn't work, it says: errno after: 33 result: nan But my platform really isn't that special: it's the Redhat 8.0 which is a very common system! At least this should be reported to glibc (?? not sure) people. Moreover, on redhat 7.3 the python 1.5 doesn't failt this test while the python 2.0 does. It's a very standard setup (a.out is the c code you suggested) [anze@as280 anze]$ ldd a.out libm.so.6 => /lib/i686/libm.so.6 (0x4002d000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 16:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 10:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 21:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 17:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 12:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 11:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 22:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Sat May 24 10:10:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 02:10:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-742342 ] Python crashes if recursively reloading modules Message-ID: <E19JV3C-0000IF-00@sc8-sf-web1.sourceforge.net> Bugs item #742342, was opened at 2003-05-23 14:03 Message generated for change (Comment added) made by chris_ce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Eder (chris_ce) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes if recursively reloading modules Initial Comment: If one tries to recursively reload modules, python crashes with a segfault. e.g. if the file "foo.py" looks something like: import foo reload (foo) .... the python interpreter crashes when reading this file. I have been able to reproduce the problem both with python2.2 and python2.3 under linux. Although recursive reloads are faulty code, this should lead to an exception but not to a segfault of the interpreter. In our case, this bug allows a faulty user script to crash our program. Sorry if this is already a known bug, but I searched in Sorceforge (and also in Google) and did not find something similar. ---------------------------------------------------------------------- >Comment By: Christian Eder (chris_ce) Date: 2003-05-24 09:10 Message: Logged In: YES user_id=785436 You're right, there's nothing wrong with recursive imports (we also use them in our sources), but with recursive reloads. As far as I know the import statement reads the module only if it is not registered in sys.modules. If modules are added to sys.modules before they are parsed (as I suppose they are) a recursive import does no harm because the module is read only once. But I think the reload statement re-reads the file unconditionally (is it so ?) and may therefore cause an endless recursion. If the interpreter keeps a graph of files and the relations which file causes a reading of another file (either by importing a file which is not yet in sys.modules or by reloading), situations like recursive reloads could be easily detected as they would introduce cycles to the graph. However this is just an idea, maybe an implementation would cost too much permance. I will research the problem further and notice you if I find some kind of workaround. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 18:56 Message: Logged In: YES user_id=31435 The default recursion limit is unconditionally defined -- it doesn't vary across platforms. If you can submit a patch, that would help. Note that there's nothing wrong with (indirectly) recursive imports in Python (they're delicate but frequently used anyway), so we can't raise an exception on that. ---------------------------------------------------------------------- Comment By: Christian Eder (chris_ce) Date: 2003-05-23 18:30 Message: Logged In: YES user_id=785436 I tried it on 2 of our development PC's and got the following results on both of them: sys.getrecursionlimit () ===> 1000 python find_recursionlimit.py ===> 2800 Seems a bit strange, doesn't it ? I had expected the sys.recursionlimit to be higher than the actual limit. Anyway, recursive reloads are quite easy to detect, so shouldn't the interpreter detect such statements and raise an appropriate error exception (not resulting in a maximum recursion depth exceeded error) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-23 16:01 Message: Logged In: YES user_id=31392 I expect this is a platform-specific problem with the Python recursion limit. Can you report two things? The value returned by sys.getrecursionlimit(), and the last limit reported by Misc/find_recursionlimit.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 From noreply@sourceforge.net Sat May 24 12:37:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 04:37:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-729317 ] comparing versions - one a float Message-ID: <E19JXLE-00033h-00@sc8-sf-web4.sourceforge.net> Bugs item #729317, was opened at 2003-04-29 05:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Larry Bugbee (thunderbug) Assigned to: Martin v. Löwis (loewis) Summary: comparing versions - one a float Initial Comment: Tkinter.py, line 1572, 2.3b1 from python.org.... Attempts to compare tcl_version with _tkinter.TCL_VERSION. Both have the same value, 8.4, but... tcl_version is a <type 'float'> and _tkinter.TCL_VERSION is a <type 'str'> Temporary kludge: wrap it... str(tcl_version) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 13:37 Message: Logged In: YES user_id=21627 Fixed as suggested in Tkinter.py 1.175. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-23 16:00 Message: Logged In: YES user_id=45365 I'm getting fed up with this bug. I uninstalled the Batteries Included distribution and installed the minimal TclTkAqua and indeed: everything worked as expected. Then I installed BI again, expecting the problem to come back, *but it didn't*. Then I asked other people on the PythonMac-SIG to do the same: for everyone the problem disappeared with the minimal install, for some it came back with the BI install, for some it didn't. I suggest we add the str() calls around the test of tcl_version and leave it at that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-19 21:48 Message: Logged In: YES user_id=21627 On incrTcl: I still cannot reproduce that. On Linux, incrTcl is typically installed, but it comes as a Tcl package. So it won't get loaded until somebody does 'package require Itcl'. On loading that package, I see no change in type of tcl_version. Grepping the source of Itcl 3.2.1, I find no occurrence of tcl_version. What specific file contains what specific access to tcl_version on your system? On using internal APIs: I see, using GetDoubleFromObj is probably better. However, it won't change the behaviour at all: Python accesses the double representation only if it already knows the Tcl object is a double. In that case, Tcl_GetDoubleFromObj does exactly the same thing that _tkinter already does. On the importance of #518625: It is important for the following reasons: a) it allows to round-trip doubles without loss of precision. That fixes #721171. b) it improves type safety, by returning the proper object types for widget attributes. c) it improves efficiency, but not requiring expensive string-object conversions. It also provides full backwards compatibility, by allowing applications to set Tkinter.wantobjects=False. I'll try to come up with a fix for this bug, although I would really prefer if I could reproduce it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-19 15:25 Message: Logged In: YES user_id=45365 I did some more investigating, and it turns out that Jim and Benjamin's analysis of the problem is correct. The distribution that most people install for MacOSX is a "batteries included" distribution of Tcl/Tk, which includes lots of optional packages that initialize themselves. Some of these initializations do a compare of tcl_version to the numeric value 8.3 or so, thereby coercing tcl_version to a float. I removed all traces of tcl/tk from my machine and installed a minimal tcl/tk and the problem does not occur. On Linux everyone apparently installs a bare tcl/tk, but once you install incrTcl or whatever yourself you will run into the same problem. As to your (Martin's) statement that _tkinter uses only official Tcl APIs: the TCL folks disagree with this. The official way to get a float from a tcl object is using Tcl_GetDoubleFromObj(), not looking at the cached internal value. A tcl object is a string, and that's all there is. Anything else is optimization. The question now is really: how important is patch #518625. It apparently breaks Tcl object semantics, is the added convenience worth it. If it is then we simply add str() calls around the comparison of tcl_version in Tkinter, but then we should remember that this same problem will show up in different guises later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-19 07:28 Message: Logged In: YES user_id=21627 I disagree that patch #518625 is in error; _tkinter uses only official Tcl API to access Tcl objects. It is certainly the case that a computation with tcl_version may cause it to change its type from string. However, I would still like to find out where exactly that happens on the Mac, as it happens nowhere else, and Tkinter most certainly does not use any Tcl code that may trigger such a change. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-18 23:22 Message: Logged In: YES user_id=45365 Martin, I'm assigning back to you, because I'm out of my water here. I discussed this problem with the MacTcl people, and it seems that what was checked in in _tkinter.c for patch 518625 is not correct: if something is initialized as a string in Tcl and then some code accesses it as a float the internal float representation will be created automatically. In other words: the FromObj() code attempts to graft Python semantics on Tcl objects, which is prone to obscure errors. Here are some excerpts from relevant mail messages: ------------- >From Jim Ingham: tcl_version is created as a string variable with the value "8.2". If somebody tried to do some math with it (like evaluate expr $tcl_version <= 8.4 or something) then Tcl would set the internal representation to a float. I don't see any place where we are doing that, but maybe your Tkinter code does that to check something on Mac OS X? Anyway that would not be an error on Tcl's part. If you want tcl_version in Python explicitly as a string, you need to make sure the string representation exists, and then get the variable as a string. You can't rely on their being or not being any particular internal representation. ------------------ And from Benjamin Riefenstahl: Well, somebody may already have told you that, but that's not how Tcl works. In Tcl *all* values are strings. You use Tcl_GetStringFromObj() to get that value. That's it. If you want a floating point, you explicitly *convert* by using Tcl_GetDoubleFromObj(). Everything you see related to "types" is just internal speed optimizations to avoid double conversions. These internal representations come and go at the whim of the implementation. Accessing these infos without the official APIs will lead to errors and inconsistent behaviour, as you have seen. The details of the behaviour will also quite likely change from Tcl version to Tcl version. --------------- ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-10 09:29 Message: Logged In: YES user_id=21627 This seems to happen only in the Mac version of Tcl. I can't reproduce it on Linux or Windows, and I can't see anything in the Tcl sources that may causing it. tcl_version is set in generic/tclBasic.c using Tcl_SetVar, i.e. as a string. It is never referred-to in the Tcl sources, except for being returned from 'info tclversion'. So I can't see why it would ever be changed to a floating point object. Perhaps the Mac is not using the original Tcl source code? Assigning to Jack for further investigation. ---------------------------------------------------------------------- Comment By: Larry Bugbee (thunderbug) Date: 2003-05-10 04:44 Message: Logged In: YES user_id=10953 Several of us have encountered this. Personally, I have seen this with Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2. ...and with Tcl/Tk 8.4.2. ...and under 10.2.5 and 2.3b1. I've tried several combinations. My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/ python/mac/ . I hope this helps. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-09 10:50 Message: Logged In: YES user_id=21627 I cannot reproduce this. What operating system is this, what is the precise Tcl version, and where can I get the source code of this Tcl version? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 00:00 Message: Logged In: YES user_id=80475 Martin, is this something you can look at in Eric's absence? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-29 07:00 Message: Logged In: YES user_id=80475 Eric, I think this was your change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729317&group_id=5470 From noreply@sourceforge.net Sat May 24 12:40:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 04:40:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-741806 ] test_long failure Message-ID: <E19JXOP-0000lE-00@sc8-sf-web3.sourceforge.net> Bugs item #741806, was opened at 2003-05-22 17:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test_long failure Initial Comment: $ python Lib/test/test_long.pyc long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow Traceback (most recent call last): File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 442, in ? test_float_overflow() File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 394, in test_float_overflow eval(test, namespace) File "<string>", line 0, in ? ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 $ This happens on Tru64Unix 5.1A, cc/cxx compiled binaries. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 13:40 Message: Logged In: YES user_id=21627 >From http://sourceforge.net/tracker/download.php?group_id=5470&atid=305470&file_id=47386&aid=719359 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-23 10:44 Message: Logged In: YES user_id=696559 Hmm, I see tthe patch in list of patches, but how to download it? :( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 23:08 Message: Logged In: YES user_id=33168 Patch 719359 should fix this problem. Can you test this patch? ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 17:54 Message: Logged In: YES user_id=696559 ${ac_dA}SIZEOF_LONG${ac_dB}SIZEOF_LONG${ac_dC}8${ac_dD} ${ac_dA}HAVE_LONG_LONG${ac_dB}HAVE_LONG_LONG${ac_dC}1${ac_dD} ${ac_dA}SIZEOF_LONG_LONG${ac_dB}SIZEOF_LONG_LONG${ac_dC}8${ac_dD} ${ac_uA}SIZEOF_LONG${ac_uB}SIZEOF_LONG${ac_uC}8${ac_uD} ${ac_uA}HAVE_LONG_LONG${ac_uB}HAVE_LONG_LONG${ac_uC}1${ac_uD} ${ac_uA}SIZEOF_LONG_LONG${ac_uB}SIZEOF_LONG_LONG${ac_uC}8${ac_uD} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 From noreply@sourceforge.net Sat May 24 12:41:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 04:41:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-717614 ] Uthread problem - Pipe left open Message-ID: <E19JXPO-0001lu-00@sc8-sf-web2.sourceforge.net> Bugs item #717614, was opened at 2003-04-08 18:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717614&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jim Ramsay (lack) Assigned to: Nobody/Anonymous (nobody) Summary: Uthread problem - Pipe left open Initial Comment: For some reason on my FreeBSD system whenever I run python I am unable to access file descriptor 3 or 4. According to my system's fstat, there is a pipe there: lack python 36683 3* pipe cd5b2cc0 <-> cd99f9e0 0 rw lack python 36683 4* pipe cd99f9e0 <-> cd5b2cc0 0 rw But I did not open this pipe, nor can I figure out where it came from. I also cannot close this file descriptor or use it in any way - I recieve the error: >>> os.close(3) Traceback (most recent call last): File "<stdin>", line 1, in ? OSError: [Errno 9] Bad file descriptor >>> There is some strange behaviour if I close one of the standard descriptors first: >>> os.close(2) >>> os.close(3) >>> os.close(4) >>> But despite the lack of error messages, the pipe from 3 to 4 is still open. I do not know why this happens. and am at a loss at how to access FD#3. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 13:41 Message: Logged In: YES user_id=21627 Closing because of lack of response. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 14:50 Message: Logged In: YES user_id=21627 Neither uthread_init.c nor uthread_execve.c are part of the Python distribution. Why do you think you have found a bug in Python? It sounds more like a bug in FreeBSD to me. ---------------------------------------------------------------------- Comment By: Jim Ramsay (lack) Date: 2003-04-08 19:30 Message: Logged In: YES user_id=185022 Update: This seems to be linked to "uthread" support. This pipe is opened in uthread_init.c around line 167, and should be closed by uthread_execve.c around line 59. For some reason the pipe is not being closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=717614&group_id=5470 From noreply@sourceforge.net Sat May 24 12:55:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 04:55:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19JXcv-0001HN-00@sc8-sf-web3.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 22:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 13:55 Message: Logged In: YES user_id=21627 That error value (33) is EDOM. It seems to me that this is the correct result, according to C99 7.12.7.4p2: The pow functions compute x raised to the power y. A domain error occurs if x is finite and negative and y is finite and not an integer value. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-24 00:48 Message: Logged In: YES user_id=447507 Of course, it doesn't work, it says: errno after: 33 result: nan But my platform really isn't that special: it's the Redhat 8.0 which is a very common system! At least this should be reported to glibc (?? not sure) people. Moreover, on redhat 7.3 the python 1.5 doesn't failt this test while the python 2.0 does. It's a very standard setup (a.out is the c code you suggested) [anze@as280 anze]$ ldd a.out libm.so.6 => /lib/i686/libm.so.6 (0x4002d000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 18:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 12:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 23:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 18:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 13:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 12:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 23:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Sat May 24 13:25:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 05:25:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-739424 ] Python2.3b1 install problems on Linux Message-ID: <E19JY5Z-0006Pd-00@sc8-sf-web1.sourceforge.net> Bugs item #739424, was opened at 2003-05-18 14:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 Category: Build >Group: Not a Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 install problems on Linux Initial Comment: I'm running Red Hat Linux 8.0, patches fully up to date, with the latest tcl/tk packages installed. Python2.2.1 is running fine, including Tkinter and IDLE. Followed the standard install procedure for Python-2.3.b1 tarball, and Tkinter is now broken. Can't install IDLE. ./configure and make ran OK. ~/Python-2.3b1> make test 227 tests OK 26 skipped 1 unexpected skip on linux2: test_bz2 No module named bz2 ~/Python-2.3b1> make install ... building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -I/usr/X11R6/include -I. -I/home/macquigg/Python-2.3b1/./Include -I/usr/local/include -I/home/macquigg/Python-2.3b1/Include -I/home/macquigg/Python-2.3b1 -c /home/macquigg/Python-2.3b1/Modules/_tkinter.c -o build/temp.linux-i686-2.3/_tkinter.o cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" /usr/include/tk.h:597: parse error before "Bool" ... many more of these parse errors ... ==> Cannot find "Xlib.h" anywhere under /usr/include, /usr/X11R6, or in the Python-2.3b1 distribution. As far as I know, the X11 files have not been altered. Python 2.2.1 still runs OK. Here are the versions on the tcl/tk packages recently downloaded from RedHat. -rw-rw-r-- 1 macquigg macquigg 1570466 May 10 11:36 tcl-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 460160 May 10 13:47 tix-8.2.0b1-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 1390929 May 10 11:40 tk-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 265427 Apr 25 04:54 tkinter-2.2.1-17.i386.rpm More details in the attached logfile. I'll try to keep this configuration together for debugging. - Dave ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 14:25 Message: Logged In: YES user_id=21627 This is not a bug in Python, then, but a system misconfiguration. Closing it. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-20 19:22 Message: Logged In: YES user_id=676422 Neal: Installing XFree86-devel-4.2.0-72 and rebuilding Python-2.3b1 solved the problem. :>) Tkinter works, and so does IDLEfork-0.9a2. :>) I'm delighted with the new functionality in IDLE. Looks like I'll be giving up on BlackAdder -- *IF* I can get IDLE to play with Qt Designer. That's my next project. I'm also very impressed with Tkinter. It might just pull me away from Qt Designer. As for the currrent Tkinter install problem in 2.3b1, its just a packaging problem that needs to be solved in the .rpm's before the final release. I don't think any normal user will be able to find Xlib.h, or know what package to install. Red Hat was no help at all. There is no way to search their packages for a file you need, inquiries get only an automated response, and they don't appear to be doing their job on checking the stuff they pack into their releases. IDLE won't even start in Red Hat 8.0. I guess it is really up to the developers to check what Red Hat distributes. Keep up the good work. - Dave ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-20 03:00 Message: Logged In: YES user_id=676422 Neal: According to Redhat Network, my package tkinter-2.2.1-17 is installed correctly, including resolution of all dependencies. I did find XFree86-devel-4.2.0-72, and I have scheduled that for installation. I'll let you know if that solves the problem. I'm suspecting a Red Hat problem. They don't do a very good job with checking these packages. Thanks for your help. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-18 22:57 Message: Logged In: YES user_id=33168 You will need the Xlib headers installed to build Tkinter. The RPM package which contains the headers is probably something like XFree86-devel-4-3.0-2. Try installing that package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 From noreply@sourceforge.net Sat May 24 15:25:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 07:25:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i Message-ID: <E19JZxj-0002AT-00@sc8-sf-web1.sourceforge.net> Bugs item #694431, was opened at 2003-02-27 15:44 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.3a2 Build fails on HP-UX11i Initial Comment: While building Python 2.3a2 on HP-UX11i I got the following error: ld -b build/temp.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.o -L/opt/python/lib - L/usr/local/lib -o build/lib.hp-ux-B.11.11- 9000/785-2.3/_iconv_codec.sl /usr/lib/dld.sl: Unresolved symbol: libiconv_open (code) from build/lib.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.sl sh[3]: 25624 Abort(coredump) *** Error exit code 134 ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2003-05-24 15:25 Message: Logged In: YES user_id=200117 Neal, since iconv was removed I can build Python 2.3 OK, therfore I'm happy for the bug report to be closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 22:48 Message: Logged In: YES user_id=33168 Richard, is this still a problem? iconv has been removed. Should this bug be closed? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-31 08:36 Message: Logged In: YES user_id=200117 Yes, I was just trying to get Python to compile. I'm not aware that we have any need for the iconv codec module. What is the best way to get the build process to omit it from the build? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 21:55 Message: Logged In: YES user_id=33168 This means the iconv_open() call is failing. Unless you know you need this module, you probably don't. And if you do need this module, you probably know more than I do. :-) So if you are just trying to get this working, I don't think it's a big deal. It seems to work on some HPUX machines. I suspect the reason the iconv_open() is failing is because of a configuration on your machine. This call is for translating character sets. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-26 16:26 Message: Logged In: YES user_id=200117 Hi Neal, I edited Modules/Setup line 483 like this: _iconv_codec _iconv_codec.c -I/usr/include I can now build Python! However test_iconv_codecs fails: capulet:dist/src > ./python ./Lib/test/test_iconv_codecs.py Traceback (most recent call last): File "./Lib/test/test_iconv_codecs.py", line 3, in ? import codecs, _iconv_codec RuntimeError: can't initialize the _iconv_codec module: iconv_open() failed I tried adding '-l:libdld.sl' to line 483 (as suggested by the man page) but the test still fails. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-26 14:43 Message: Logged In: YES user_id=200117 Hi Neal, I have now discovered that there is a different version of iconv.h on my workstation in /usr/local/include. It appears to be part of the zlib package and it contains the pre-processor macros which are converting the iconv statements to libiconv. It is being used instead of the one in /usr/include, because the compile command contains -I/usr/local/include Is there any easy to prevent this path from being added to the compile commands? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-25 17:51 Message: Logged In: YES user_id=200117 Neal, The original error referred to unresolved symbol 'libiconv_open'. The source module _iconv_codec.c contains calls to iconv_open(), not libiconv_open(). However, if I recompile it with the -E flag there is a pre- processor substitution happening which is converting all instances of 'iconv' to 'libiconv' Here I grepped the pre-processor output for 'iconv'... extern int _libiconv_version; typedef void* libiconv_t ; extern libiconv_t libiconv_open (const char* tocode, const char* fromcode); extern size_t libiconv (libiconv_t cd, char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); extern int libiconv_close (libiconv_t cd); extern int libiconvctl (libiconv_t cd, int request, void* argument); libiconv_t enchdl, dechdl; if (libiconv (self->enchdl, (char**)&inp, &inplen, &out, &outlen) size_t res = libiconv (self->dechdl, (char**)&inp, &inplen, &out, &outlen); new->enchdl = new->dechdl = (libiconv_t )(-1); new->dechdl = libiconv_open ("ucs-2-internal" , new->encoding); if (new->dechdl == (libiconv_t )(-1)) { new->enchdl = libiconv_open (new->encoding, "ucs- 2-internal" ); if (new->enchdl == (libiconv_t )(-1)) { libiconv_close (new->dechdl); new->dechdl = (libiconv_t )(-1); if (self->enchdl != (libiconv_t )-1) libiconv_close (self->enchdl); if (self->dechdl != (libiconv_t )-1) libiconv_close (self->dechdl); libiconv_t hdl = libiconv_open ("ucs-2- internal" , "ISO-8859-1"); if (hdl == (libiconv_t )-1) { res = libiconv (hdl, &inptr, &insize, &outptr, &outsize); libiconv_close (hdl); libiconv_close (hdl); Is this supposed to be happening?? If not, what could be causing it?? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 15:52 Message: Logged In: YES user_id=33168 Looking further into the python configure, I see that the option is --with-dl-dld, however, this option is not supported. Can try to play with the build options to find the magic that works on your version of HPUX? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 15:48 Message: Logged In: YES user_id=33168 Richard, in the manpage it says that iconv has a dependancy on libdld.sl. Perhaps you need to configure python --with-dld. Can you try that? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-04 17:09 Message: Logged In: YES user_id=200117 Neal, I will try to help, but internet access is difficult at work so responses may not be prompt. I had a look at the man page but it was not clear to me which library contains iconv_open. I will attach text copy of the man page for you. I also include some nm output from libc.sl which refers to iconv_open, but I'm not sure if it means that it contains the code for the function. Let me know if I can try anything else. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 22:15 Message: Logged In: YES user_id=33168 Richard, can you help diagnose further since I can't reproduce on HP-UX 11.00? My initial guess is that iconv_open is in a different location, therefore the linking is faililng. Does man iconv_open reveal what library iconv_open is in? To add directories, etc. to the build/link of iconv, you will need to edit setup.py (or test on the command line). Check around line 620 in setup.py. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-03 09:14 Message: Logged In: YES user_id=200117 Sorry for the delay but I had to download from CVS at home yesterday (Sunday 2nd) and build on HP-UX at work today. Unfortunately I'm still getting the same linker error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 17:37 Message: Logged In: YES user_id=33168 This iconv_codec problem may be fixed. Please test with current CVS to verify. See SF bug #690012. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 03:45 Message: Logged In: YES user_id=33168 Richard, can you try the latest version from CVS. I don't have this problem on hp-ux-B.11.00-9000/829 I do have a problem with readline, but I think that's specific to the machine I'm building on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 From noreply@sourceforge.net Sat May 24 16:52:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 08:52:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-739424 ] Python2.3b1 install problems on Linux Message-ID: <E19JbJv-0005Hl-00@sc8-sf-web1.sourceforge.net> Bugs item #739424, was opened at 2003-05-18 05:10 Message generated for change (Comment added) made by macquigg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 Category: Build Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 install problems on Linux Initial Comment: I'm running Red Hat Linux 8.0, patches fully up to date, with the latest tcl/tk packages installed. Python2.2.1 is running fine, including Tkinter and IDLE. Followed the standard install procedure for Python-2.3.b1 tarball, and Tkinter is now broken. Can't install IDLE. ./configure and make ran OK. ~/Python-2.3b1> make test 227 tests OK 26 skipped 1 unexpected skip on linux2: test_bz2 No module named bz2 ~/Python-2.3b1> make install ... building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -I/usr/X11R6/include -I. -I/home/macquigg/Python-2.3b1/./Include -I/usr/local/include -I/home/macquigg/Python-2.3b1/Include -I/home/macquigg/Python-2.3b1 -c /home/macquigg/Python-2.3b1/Modules/_tkinter.c -o build/temp.linux-i686-2.3/_tkinter.o cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" /usr/include/tk.h:597: parse error before "Bool" ... many more of these parse errors ... ==> Cannot find "Xlib.h" anywhere under /usr/include, /usr/X11R6, or in the Python-2.3b1 distribution. As far as I know, the X11 files have not been altered. Python 2.2.1 still runs OK. Here are the versions on the tcl/tk packages recently downloaded from RedHat. -rw-rw-r-- 1 macquigg macquigg 1570466 May 10 11:36 tcl-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 460160 May 10 13:47 tix-8.2.0b1-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 1390929 May 10 11:40 tk-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 265427 Apr 25 04:54 tkinter-2.2.1-17.i386.rpm More details in the attached logfile. I'll try to keep this configuration together for debugging. - Dave ---------------------------------------------------------------------- >Comment By: David MacQuigg (macquigg) Date: 2003-05-24 08:52 Message: Logged In: YES user_id=676422 Martin: I'm not sure what you mean by a "system misconfiguration", and I'm concerned that this problem will occur with the final release of Python-2.3 on Red Hat Linux. My system is completely up to date with the latest Red Hat 8 patches. The missing package XFree86-devel is not one that is normally installed as part of the Red Hat standard system configuration. A dependency like this should be resolved in the packages that require it. Given the history of problems with IDLE and tkinter in Red Hat 8 and 9, it is clear to me that no testing of these modules is done on the packages that Red Hat distributes. This looks like a problem that falls in a crack between the developers and the distributors. Whoever assembles the Python-2.3 package for Red Hat should be aware of these problems. Perhaps the Python developers could put together a test script that runs IDLE, and any other module in Python-2.3 that might depend on the "system configuration". Then any time there is some change in the system, the Python packager (whoever that might be) could just run the test script, see that there is a missing "Xlib.h" or whatever, locate that file in the other packages that are part of the distribution, and add the proper dependency to the Python package. Users installing Python-2.3 will then be able to resolve these package-level dependencies as they do with any other package. I hope this is helpful, not just a nag. The new IDLE is great. I got it working with Qt Designer, and now my Python-Qt "IDE" is complete. Goodby BlackAdder. - Dave ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 05:25 Message: Logged In: YES user_id=21627 This is not a bug in Python, then, but a system misconfiguration. Closing it. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-20 10:22 Message: Logged In: YES user_id=676422 Neal: Installing XFree86-devel-4.2.0-72 and rebuilding Python-2.3b1 solved the problem. :>) Tkinter works, and so does IDLEfork-0.9a2. :>) I'm delighted with the new functionality in IDLE. Looks like I'll be giving up on BlackAdder -- *IF* I can get IDLE to play with Qt Designer. That's my next project. I'm also very impressed with Tkinter. It might just pull me away from Qt Designer. As for the currrent Tkinter install problem in 2.3b1, its just a packaging problem that needs to be solved in the .rpm's before the final release. I don't think any normal user will be able to find Xlib.h, or know what package to install. Red Hat was no help at all. There is no way to search their packages for a file you need, inquiries get only an automated response, and they don't appear to be doing their job on checking the stuff they pack into their releases. IDLE won't even start in Red Hat 8.0. I guess it is really up to the developers to check what Red Hat distributes. Keep up the good work. - Dave ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-19 18:00 Message: Logged In: YES user_id=676422 Neal: According to Redhat Network, my package tkinter-2.2.1-17 is installed correctly, including resolution of all dependencies. I did find XFree86-devel-4.2.0-72, and I have scheduled that for installation. I'll let you know if that solves the problem. I'm suspecting a Red Hat problem. They don't do a very good job with checking these packages. Thanks for your help. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-18 13:57 Message: Logged In: YES user_id=33168 You will need the Xlib headers installed to build Tkinter. The RPM package which contains the headers is probably something like XFree86-devel-4-3.0-2. Try installing that package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 From noreply@sourceforge.net Sat May 24 17:08:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 09:08:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19JbYz-00034W-00@sc8-sf-web2.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 16:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 12:08 Message: Logged In: YES user_id=31435 That's the relevant bit, yes. The subtlety is that a *is* an integer: any double with a very large exponent is an exact integer. Python checks for this by seeing whether a == floor (a); a semantically equivalent check would be to call modf (a) and see whether the fractional part returned is exactly 0.0, same-as whether the integer part returned is exactly a (which it is, for any fp # w/ a sufficiently large exponent -- unless this math library's implementation of modf is buggy too). Consider the alternative (which is what *this* platform pow appears to do): raising -1 to 1 works fine, to 1e1 works fine, to 1e2 works fine, to 1e3 works fine, to 1e4 works fine, to 1e5 works fine, ..., but at some senseless point it blows up with a domain error. As n increases, when does 10.0**n stop being "an integer"? Of course it doesn't, at least not before n is so large that 10.0**n overflows by itself. Note IEEE 754 does not view doubles as "fuzzy approximations" -- it always takes them exactly at face value, and computes the best possible result based on that. Python does this check explicitly to worm around other bugs in other libms, in order to raise ValueError when x < 0 and y is not an integer, just as the standard says. The only exception that should be possible in the cases Python passes on to the libm pow is overflow, and this platform pow () is wrong in this case. It's too hard to check for overflow a priori in a platform-independent way, and that's why we leave that part up to the platform pow(). Note that the OP is complaining about an assertion error, which means he's running a debug-build Python. I think it's thoroughly appropriate to whine about platform bugs too in a debug build. In a release build, the assert doesn't exist, and Python would raise a Python exception instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 07:55 Message: Logged In: YES user_id=21627 That error value (33) is EDOM. It seems to me that this is the correct result, according to C99 7.12.7.4p2: The pow functions compute x raised to the power y. A domain error occurs if x is finite and negative and y is finite and not an integer value. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 18:48 Message: Logged In: YES user_id=447507 Of course, it doesn't work, it says: errno after: 33 result: nan But my platform really isn't that special: it's the Redhat 8.0 which is a very common system! At least this should be reported to glibc (?? not sure) people. Moreover, on redhat 7.3 the python 1.5 doesn't failt this test while the python 2.0 does. It's a very standard setup (a.out is the c code you suggested) [anze@as280 anze]$ ldd a.out libm.so.6 => /lib/i686/libm.so.6 (0x4002d000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 12:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 06:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 12:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 07:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 06:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 17:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Sat May 24 17:49:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 09:49:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-620412 ] Max recursion limit with "*?" pattern Message-ID: <E19JcDH-0007ap-00@sc8-sf-web1.sourceforge.net> Bugs item #620412, was opened at 2002-10-08 19:40 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620412&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: Max recursion limit with "*?" pattern Initial Comment: I ran into the following problem trying to parse an ms outlook mail box. Cut down to its bare essentials: > cat tst.py import re mstr = (11000*' ') + 'A' pattern = re.compile('.*?A') pattern.search(mstr) > python tst.py Traceback (most recent call last): File "tst.py", line 5, in ? pattern.search(mstr) RuntimeError: maximum recursion limit exceeded > python Python 2.2.1c1 (#6, Jul 20 2002, 09:40:07) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> The combination of a longish string with ".*?" gives the error. Using ".*" is ok. Could "non-greedy" matching be implemented non-recursively? If I understand correctly, the limit exceeded is USE_RECURSION_LIMIT in Modules/_sre.c. It is slightly confusing because we also have the Python recursion limit (my first reaction was to bump it up with sys.setrecursionlimit(), but that of course didn't help). ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-05-24 16:49 Message: Logged In: YES user_id=7887 As Gary Herron correctly pointed me out, this was fixed in 2.3 with the introduction of a new opcode to handle single character non-greedy matching. This won't be fixed in 2.2.3, but hopefully will be backported to 2.2.4 together with other regular expression fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620412&group_id=5470 From noreply@sourceforge.net Sat May 24 17:52:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 09:52:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-602444 ] non greedy match bug Message-ID: <E19JcFY-00044l-00@sc8-sf-web3.sourceforge.net> Bugs item #602444, was opened at 2002-08-30 14:44 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602444&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Roy (rjroy) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: non greedy match bug Initial Comment: When using the following re to extract all objects from a PDF file, I get a maximum recursion limit exceeded error. Attached is a pdf file that will reproduce the error. If I do import pre as re, it works fine. platform is Win2k, Python 2.2.1 build #34 ####### import re GETOBJECT = re.compile(r'\d+\s+\d+\s+obj.+?endobj', re.I|re.S|re.M) pdf = open('userguide.pdf', 'rb').read() all = GETOBJECT.findall(pdf) print len(all) ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-05-24 16:52 Message: Logged In: YES user_id=7887 As Gary Herron correctly pointed me out, this was fixed in 2.3 with the introduction of a new opcode to handle single character non-greedy matching. This won't be fixed in 2.2.3, but hopefully will be backported to 2.2.4 together with other regular expression fixes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 05:54 Message: Logged In: YES user_id=357491 Closing this since hitting the recursion limit is not a bug. ---------------------------------------------------------------------- Comment By: Robert Roy (rjroy) Date: 2003-02-14 18:56 Message: Logged In: YES user_id=352797 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602444&group_id=5470 From noreply@sourceforge.net Sat May 24 17:55:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 09:55:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: <E19JcJK-0004WO-00@sc8-sf-web4.sourceforge.net> Bugs item #493252, was opened at 2001-12-14 10:54 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: P. de Jong (peterdejong) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-05-24 16:55 Message: Logged In: YES user_id=7887 As Gary Herron correctly pointed me out, this was fixed in 2.3 with the introduction of a new opcode to handle single character non-greedy matching. This won't be fixed in 2.2.3, but hopefully will be backported to 2.2.4 together with other regular expression fixes. ---------------------------------------------------------------------- Comment By: Quentin Crain (nanotech) Date: 2002-09-10 16:12 Message: Logged In: YES user_id=191231 I am hoping this is a useful comment/code: import re s1=('macro\n'+'a'*200+'\norcam\n')*10 s2=('macro\n'+'a'*20000+'\norcam\n')*10 p=re.compile(r'macro.*?orcam',re.DOTALL) for x in re.findall(p,s1): print x for x in re.findall(p,s2): print x Using re.findall bit the users I support because it could not scale with the data. Thanks for your efforts! Quentin Crain ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 18:15 Message: Logged In: YES user_id=31435 I'm afraid Guido's rewrite stacks a backtracking point for each character, so it can still die on strings of the length you're looking at. For example, here's a ~16KB string that kills it on Windows: test = '"' + ('a' * 128 + '""') * 128 + '";' The only info I know of on how to write robust regexps is in Friedl's "Mastering Regular Expressions" book, which does an excellent job. Using his "unrolling" pattern leads to the regexp r'"[^"]*(""[^"]*)*"[;\n]' which is an instance of the general normal* (special normal*)* pattern, and reduces the number of stacked backtracking points from the number of characters in the string to the number of special strings within it (given various preconditions that happen to be satisfied here -- you really need to read the book, as it resists a pithy summary). That works fine with the test string above, and even if you change it to test = '"' + ('a' * 5000 + '""') * 5000 + '";' At that point you're matching a 25MB string, which should be big enough for most web use <wink>. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 17:00 Message: Logged In: YES user_id=6380 I don't think that would make a difference. I don't understand SRE enough to know where the recursion cascade comes from; maybe Tim or Fredrik can explain? I believe it has something to do with an unexpected behavior of the *? operator. Note that it's a well-known theoretical result that parsing ambiguous languages can be O(n**3), so you might want to rethink this decision. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 16:47 Message: Logged In: YES user_id=402001 Guido, Indeed. in many cases my language is ambious. I will try your solution. It is not clear to me what induces the recursion; Maybe something like '(?s)"(.*?)(";|"\n)' will not give the recursion cascade? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:08 Message: Logged In: YES user_id=6380 Peter, if the internal quotes are doubled, try this: r'"([^"]|"")*"[;\n]' if you can't trust them to be doubled, you're in trouble -- your language is ambiguous. :-( ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 09:02 Message: Logged In: YES user_id=402001 Tim and Guido, I want to match things like: "jlkjkl ""kjlklkjkl""ljk ;lkk;l"; or: "jlkjkl ""kjlklkjkl""ljk ;lkk;l" Maybe I can trust the embedded quotes to be doubled, but I was not sure at the moment of writing the expression. I do have to include newlines inside the enclosing quotes. Peter de Jong ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 04:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 01:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 19:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion <wink>), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 16:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 13:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 16:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. </F> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 15:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 13:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Sat May 24 17:57:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 09:57:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-418626 ] maximum recursion limit exceeded (2.1) Message-ID: <E19JcL0-0004a6-00@sc8-sf-web4.sourceforge.net> Bugs item #418626, was opened at 2001-04-24 19:23 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: maximum recursion limit exceeded (2.1) Initial Comment: % /usr/bin/env python2.1 Python 2.1 (#2, Apr 24 2001, 11:33:06) [GCC 2.95.3 20010315 (release)] on hp-uxB Type "copyright", "credits" or "license" for more information. >>> % uname -a HP-UX wshelley B.11.00 A 9000/785 2014123772 two-user license % rebug.py Traceback (most recent call last): File "rebug.py", line 205, in ? re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output, re.S) File "/usr/local/lib/python2.1/sre.py", line 57, in search return _compile(pattern, flags).search(string) RuntimeError: maximum recursion limit exceeded rebug.py script works correctly using python1.5.2 I submitted this bug as a followup to [ #215696 ] sre RuntimeError when .*? matches >16K string ##### The following is the rebug.py file #!/usr/bin/env python2.1 import re output = """Using == Data Table == s m:d mb 3.300000 0.000104772187944365 -1.23330767339032e-15 3.200000 0.000103862130408037 -1.23481086168441e-15 3.100000 0.000102831826202984 -1.23643366708223e-15 3.000000 0.000101671354638586 -1.23819069775402e-15 2.900000 0.000100370082245968 -1.24009908383179e-15 2.800000 9.89166376398503e-05 -1.24217904419247e-15 2.700000 9.72988932844521e-05 -1.24445461136295e-15 2.600000 9.55039568198016e-05 -1.24695456774457e-15 2.500000 9.3518175238995e-05 -1.24971366756711e-15 2.400000 9.13271559565959e-05 -1.25277425005882e-15 2.300000 8.89158096852735e-05 -1.25618839559713e-15 2.200000 8.62684210547775e-05 -1.26002084671538e-15 2.100000 8.33687540802062e-05 -1.26435302405962e-15 2.000000 8.02002009414518e-05 -1.26928863786894e-15 1.900000 7.67459841300842e-05 -1.27496167015724e-15 1.800000 7.29894239935539e-05 -1.28154795600633e-15 1.700000 6.89142864097651e-05 -1.28928236065365e-15 1.600000 6.45052296412595e-05 -1.29848488989922e-15 1.500000 5.97483776126083e-05 -1.30960148694006e-15 1.400000 5.46320649249439e-05 -1.32326977154928e-15 1.300000 4.91478435825781e-05 -1.3404286750276e-15 1.200000 4.32919623998454e-05 -1.36250830892367e-15 1.100000 3.70678871330223e-05 -1.39177202537724e-15 1.000000 3.04915786576429e-05 -1.43195494399345e-15 0.900000 2.36052666077545e-05 -1.48947100843164e-15 0.800000 1.65202853321069e-05 -1.57551564136398e-15 0.700000 9.56073716566518e-06 -1.70791288744525e-15 0.600000 3.67125710597e-06 -1.89923336361812e-15 0.500000 6.00021904261974e-07 -2.08381565027337e-15 0.400000 4.27864345038415e-08 -2.14973379503184e-15 0.300000 2.5741570279509e-09 -2.15852923041729e-15 0.200000 1.60325700603365e-10 -2.15762110254924e-15 0.100000 1.10181009347061e-11 -2.15430351925385e-15 0.000000 9.18460199298261e-13 -2.14607756126421e-15 -0.100000 8.2907448480307e-14 -2.13154544128925e-15 -0.200000 9.49291906644266e-15 -2.09562596113738e-15 -0.300000 2.57398712712903e-15 -1.89144055818718e-15 -0.400000 1.23896929747012e-15 -1.18482371296596e-15 -0.500000 4.77088843470797e-16 -4.74259070979461e-16 3.300000 0.000725333230235404 -1.60279744215745e-14 3.200000 0.000698989627849489 -1.57983897758426e-14 3.100000 0.000672395787137216 -1.55721529060957e-14 3.000000 0.000645566845212758 -1.53549883971193e-14 2.900000 0.000618516906916818 -1.51624220311135e-14 2.800000 0.000591259277466284 -1.50347782956977e-14 2.700000 0.000563806714724985 -1.5069525306854e-14 2.600000 0.000536171704020601 -1.54848062262748e-14 2.500000 0.000508366761845922 -1.67334737461837e-14 2.400000 0.000480404778779427 -1.96904798125589e-14 2.300000 0.00045229941701671 -2.59347024715496e-14 2.200000 0.000424065584744255 -3.81354821168744e-14 2.100000 0.000395720019338978 -6.05316531752639e-14 2.000000 0.000367282025836478 -9.9457021513997e-14 1.900000 0.000338774439198852 -1.63825993533288e-13 1.800000 0.000310224913488982 -2.65456611717139e-13 1.700000 0.000281667696431468 -4.19089961445906e-13 1.600000 0.000253146138686846 -6.4197984099406e-13 1.500000 0.000224716340367884 -9.52983499747302e-13 1.400000 0.00019645260393449 -1.37117106753005e-12 1.300000 0.000168455842857815 -1.9140171376089e-12 1.200000 0.000140866992561325 -2.5949957749272e-12 1.100000 0.000113889209694637 -3.419066099784e-12 1.000000 8.78261401150504e-05 -4.36958009251635e-12 0.900000 6.31506490822963e-05 -5.36461118003355e-12 0.800000 4.06312963119592e-05 -6.12577475587495e-12 0.700000 2.15481889941145e-05 -5.92418822150058e-12 0.600000 7.87604367966821e-06 -3.80859906972703e-12 0.500000 1.3904896761789e-06 -9.79870732426348e-13 0.400000 1.06064890626322e-07 -9.39992702457847e-14 0.300000 6.34950130197645e-09 -1.65503941397823e-14 0.200000 3.88292805625561e-10 -1.16204226732226e-14 0.100000 2.57865399432747e-11 -1.11870703136006e-14 0.000000 2.05458930149398e-12 -1.09482596289954e-14 -0.100000 1.85578779234532e-13 -1.06729449780495e-14 -0.200000 2.5577583052963e-14 -1.02232392679007e-14 -0.300000 1.05769385343133e-14 -9.2322860676878e-15 -0.400000 8.00273522170935e-15 -7.88228414475344e-15 -0.500000 6.51965630664677e-15 -6.50815076902941e-15 3.300000 0.000778073989265561 -1.65574096734398e-07 3.200000 0.00074963150963251 -1.92244746339178e-07 3.100000 0.000721015586364691 -2.21197891556889e-07 3.000000 0.000692226507232058 -2.52254070463242e-07 2.900000 0.000663264988754168 -2.85152554002688e-07 2.800000 0.000634132321079485 -3.19546222567145e-07 2.700000 0.000604830546549725 -3.54998299569146e-07 2.600000 0.000575362679604795 -3.90981285317844e-07 2.500000 0.000545732977654778 -4.26878409205096e-07 2.400000 0.000515947275272665 -4.61987879332959e-07 2.300000 0.000486013397947319 -4.95530155074015e-07 2.200000 0.000455941677304999 -5.26658398699649e-07 2.100000 0.000425745598153737 -5.54472176489517e-07 2.000000 0.000395442620520435 -5.78034377120716e-07 1.900000 0.000365055239615154 -5.96391194651538e-07 1.800000 0.000334612377612625 -6.0859488246625e-07 1.700000 0.000304151250425071 -6.13728816719563e-07 1.600000 0.000273719932661724 -6.1093419812057e-07 1.500000 0.000243380977243086 -5.99437433988553e-07 1.400000 0.000213216675616044 -5.78576796961394e-07 1.300000 0.000183336956663227 -5.47826196051382e-07 1.200000 0.000153891700661593 -5.06812695554088e-07 1.100000 0.000125090796710056 -4.55323667088038e-07 1.000000 9.7238530664174e-05 -3.9330616509577e-07 0.900000 7.07959411929754e-05 -3.20910962327376e-07 0.800000 4.64992533700793e-05 -2.38877973057319e-07 0.700000 2.55795422135307e-05 -1.50458199069334e-07 0.600000 1.00314893206752e-05 -6.74343626580743e-08 0.500000 2.00947524041218e-06 -1.48839482947924e-08 0.400000 1.67232105200131e-07 -1.2816627677716e-09 0.300000 1.00809637284154e-08 -7.82708572696571e-11 0.200000 6.12196843592758e-10 -4.83619605089934e-12 0.100000 4.0027953235145e-11 -3.39466185939354e-13 0.000000 3.1163322565507e-12 -4.38427713973686e-14 -0.100000 2.82036148373174e-13 -2.01235539818538e-14 -0.200000 4.04726306794353e-14 -1.75747562532315e-14 -0.300000 1.83397331593843e-14 -1.63366924660679e-14 -0.400000 1.50709750319906e-14 -1.48901998089388e-14 -0.500000 1.34240392889815e-14 -1.34063683071726e-14 3.300000 0.000104772187944365 -1.23330767339032e-15 3.200000 0.000103862130408037 -1.23481086168441e-15 3.100000 0.000102831826202984 -1.23643366708223e-15 3.000000 0.000101671354638586 -1.23819069775402e-15 2.900000 0.000100370082245968 -1.24009908383179e-15 2.800000 9.89166376398503e-05 -1.24217904419247e-15 2.700000 9.72988932844521e-05 -1.24445461136295e-15 2.600000 9.55039568198016e-05 -1.24695456774457e-15 2.500000 9.3518175238995e-05 -1.24971366756711e-15 2.400000 9.13271559565959e-05 -1.25277425005882e-15 2.300000 8.89158096852735e-05 -1.25618839559713e-15 2.200000 8.62684210547775e-05 -1.26002084671538e-15 2.100000 8.33687540802062e-05 -1.26435302405962e-15 2.000000 8.02002009414518e-05 -1.26928863786894e-15 1.900000 7.67459841300842e-05 -1.27496167015724e-15 1.800000 7.29894239935539e-05 -1.28154795600633e-15 1.700000 6.89142864097651e-05 -1.28928236065365e-15 1.600000 6.45052296412595e-05 -1.29848488989922e-15 1.500000 5.97483776126083e-05 -1.30960148694006e-15 1.400000 5.46320649249439e-05 -1.32326977154928e-15 1.300000 4.91478435825781e-05 -1.3404286750276e-15 1.200000 4.32919623998454e-05 -1.36250830892367e-15 1.100000 3.70678871330223e-05 -1.39177202537724e-15 1.000000 3.04915786576429e-05 -1.43195494399345e-15 0.900000 2.36052666077545e-05 -1.48947100843164e-15 0.800000 1.65202853321069e-05 -1.57551564136398e-15 0.700000 9.56073716566518e-06 -1.70791288744525e-15 0.600000 3.67125710597e-06 -1.89923336361812e-15 0.500000 6.00021904261974e-07 -2.08381565027337e-15 0.400000 4.27864345038415e-08 -2.14973379503184e-15 0.300000 2.5741570279509e-09 -2.15852923041729e-15 0.200000 1.60325700603365e-10 -2.15762110254924e-15 0.100000 1.10181009347061e-11 -2.15430351925385e-15 0.000000 9.18460199298261e-13 -2.14607756126421e-15 -0.100000 8.2907448480307e-14 -2.13154544128925e-15 -0.200000 9.49291906644266e-15 -2.09562596113738e-15 -0.300000 2.57398712712903e-15 -1.89144055818718e-15 -0.400000 1.23896929747012e-15 -1.18482371296596e-15 -0.500000 4.77088843470797e-16 -4.74259070979461e-16 3.300000 0.000725333230235404 -1.60279744215745e-14 3.200000 0.000698989627849489 -1.57983897758426e-14 3.100000 0.000672395787137216 -1.55721529060957e-14 3.000000 0.000645566845212758 -1.53549883971193e-14 2.900000 0.000618516906916818 -1.51624220311135e-14 2.800000 0.000591259277466284 -1.50347782956977e-14 2.700000 0.000563806714724985 -1.5069525306854e-14 2.600000 0.000536171704020601 -1.54848062262748e-14 2.500000 0.000508366761845922 -1.67334737461837e-14 2.400000 0.000480404778779427 -1.96904798125589e-14 2.300000 0.00045229941701671 -2.59347024715496e-14 2.200000 0.000424065584744255 -3.81354821168744e-14 2.100000 0.000395720019338978 -6.05316531752639e-14 2.000000 0.000367282025836478 -9.9457021513997e-14 1.900000 0.000338774439198852 -1.63825993533288e-13 1.800000 0.000310224913488982 -2.65456611717139e-13 1.700000 0.000281667696431468 -4.19089961445906e-13 1.600000 0.000253146138686846 -6.4197984099406e-13 1.500000 0.000224716340367884 -9.52983499747302e-13 1.400000 0.00019645260393449 -1.37117106753005e-12 1.300000 0.000168455842857815 -1.9140171376089e-12 1.200000 0.000140866992561325 -2.5949957749272e-12 1.100000 0.000113889209694637 -3.419066099784e-12 1.000000 8.78261401150504e-05 -4.36958009251635e-12 0.900000 6.31506490822963e-05 -5.36461118003355e-12 0.800000 4.06312963119592e-05 -6.12577475587495e-12 0.700000 2.15481889941145e-05 -5.92418822150058e-12 0.600000 7.87604367966821e-06 -3.80859906972703e-12 0.500000 1.3904896761789e-06 -9.79870732426348e-13 0.400000 1.06064890626322e-07 -9.39992702457847e-14 0.300000 6.34950130197645e-09 -1.65503941397823e-14 0.200000 3.88292805625561e-10 -1.16204226732226e-14 0.100000 2.57865399432747e-11 -1.11870703136006e-14 0.000000 2.05458930149398e-12 -1.09482596289954e-14 -0.100000 1.85578779234532e-13 -1.06729449780495e-14 -0.200000 2.5577583052963e-14 -1.02232392679007e-14 -0.300000 1.05769385343133e-14 -9.2322860676878e-15 -0.400000 8.00273522170935e-15 -7.88228414475344e-15 -0.500000 6.51965630664677e-15 -6.50815076902941e-15 """ re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output, re.S) ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-05-24 16:57 Message: Logged In: YES user_id=7887 As Gary Herron correctly pointed me out, this was fixed in 2.3 with the introduction of a new opcode to handle single character non-greedy matching. This won't be fixed in 2.2.3, but hopefully will be backported to 2.2.4 together with other regular expression fixes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 23:50 Message: Logged In: YES user_id=357491 Is this bug still a problem? No problem under OS X using 2.3b1. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-02 11:23 Message: Logged In: NO I have the same problem, running Python 2.1.3. It works well under Windows XP, but fails under Linux. Both Python 2.1.3. This is the pattern I am trying to match: (<table.*?>[\s,\S]*?</table>) I use re.split in order to group code outside tables and code inside tables. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-25 03:28 Message: Logged In: YES user_id=31435 Assigned to /F. Works for me on Win98 under 2.1. Binding m to the re result and then printing print m.span(), len(output), m.span(1), m.span(2) yields (8, 12112) 12112 (25, 43) (44, 12111) Anonymous, this is a poor use for regexps: the code would be clearer, simpler and faster (plus it wouldn't blow up <wink>) if you used basic string operations instead. The (.*?)\s*$ at the end is especially wasteful: you're teilling the regexp engine to do 12,000+ useless match attempts there, when all you *want* is the entire tail end of the string stripped of trailing whitespace. So just grab the tail end of the string directly and do string.rstrip() on it; saves 12,000+ useless matching attempts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470 From noreply@sourceforge.net Sat May 24 18:16:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 10:16:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-739424 ] Python2.3b1 install problems on Linux Message-ID: <E19JcdB-000653-00@sc8-sf-web2.sourceforge.net> Bugs item #739424, was opened at 2003-05-18 14:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 Category: Build Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 install problems on Linux Initial Comment: I'm running Red Hat Linux 8.0, patches fully up to date, with the latest tcl/tk packages installed. Python2.2.1 is running fine, including Tkinter and IDLE. Followed the standard install procedure for Python-2.3.b1 tarball, and Tkinter is now broken. Can't install IDLE. ./configure and make ran OK. ~/Python-2.3b1> make test 227 tests OK 26 skipped 1 unexpected skip on linux2: test_bz2 No module named bz2 ~/Python-2.3b1> make install ... building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -I/usr/X11R6/include -I. -I/home/macquigg/Python-2.3b1/./Include -I/usr/local/include -I/home/macquigg/Python-2.3b1/Include -I/home/macquigg/Python-2.3b1 -c /home/macquigg/Python-2.3b1/Modules/_tkinter.c -o build/temp.linux-i686-2.3/_tkinter.o cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" /usr/include/tk.h:597: parse error before "Bool" ... many more of these parse errors ... ==> Cannot find "Xlib.h" anywhere under /usr/include, /usr/X11R6, or in the Python-2.3b1 distribution. As far as I know, the X11 files have not been altered. Python 2.2.1 still runs OK. Here are the versions on the tcl/tk packages recently downloaded from RedHat. -rw-rw-r-- 1 macquigg macquigg 1570466 May 10 11:36 tcl-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 460160 May 10 13:47 tix-8.2.0b1-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 1390929 May 10 11:40 tk-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 265427 Apr 25 04:54 tkinter-2.2.1-17.i386.rpm More details in the attached logfile. I'll try to keep this configuration together for debugging. - Dave ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 19:16 Message: Logged In: YES user_id=21627 You have installed Python 2.3 from the *tarball*, right? What kind of package dependency did you expect??? Yes, packagers should be aware that they need header files to compile things. Any packager worth her money will know that, and will know how to obtain header files. On the resulting binary packages, no dependency to the header files exists: the package containing _tkinter.so only depends on the package providing libtcl.so, not on tcl-dev, and not on X11-dev. It has always been this way, and always will be; nothing has ever fallen in a crack. One might wonder why the Redhat package containing the tk header does not depend on the package containing the X11 headers, so that might be a bug in those packages. However, it would be a Redhat bug, not a Python bug. Most likely, Redhat won't consider it a bug, since you can use the Tcl/Tk headers without X11 if you are interested only in the Tcl part of that. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-24 17:52 Message: Logged In: YES user_id=676422 Martin: I'm not sure what you mean by a "system misconfiguration", and I'm concerned that this problem will occur with the final release of Python-2.3 on Red Hat Linux. My system is completely up to date with the latest Red Hat 8 patches. The missing package XFree86-devel is not one that is normally installed as part of the Red Hat standard system configuration. A dependency like this should be resolved in the packages that require it. Given the history of problems with IDLE and tkinter in Red Hat 8 and 9, it is clear to me that no testing of these modules is done on the packages that Red Hat distributes. This looks like a problem that falls in a crack between the developers and the distributors. Whoever assembles the Python-2.3 package for Red Hat should be aware of these problems. Perhaps the Python developers could put together a test script that runs IDLE, and any other module in Python-2.3 that might depend on the "system configuration". Then any time there is some change in the system, the Python packager (whoever that might be) could just run the test script, see that there is a missing "Xlib.h" or whatever, locate that file in the other packages that are part of the distribution, and add the proper dependency to the Python package. Users installing Python-2.3 will then be able to resolve these package-level dependencies as they do with any other package. I hope this is helpful, not just a nag. The new IDLE is great. I got it working with Qt Designer, and now my Python-Qt "IDE" is complete. Goodby BlackAdder. - Dave ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 14:25 Message: Logged In: YES user_id=21627 This is not a bug in Python, then, but a system misconfiguration. Closing it. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-20 19:22 Message: Logged In: YES user_id=676422 Neal: Installing XFree86-devel-4.2.0-72 and rebuilding Python-2.3b1 solved the problem. :>) Tkinter works, and so does IDLEfork-0.9a2. :>) I'm delighted with the new functionality in IDLE. Looks like I'll be giving up on BlackAdder -- *IF* I can get IDLE to play with Qt Designer. That's my next project. I'm also very impressed with Tkinter. It might just pull me away from Qt Designer. As for the currrent Tkinter install problem in 2.3b1, its just a packaging problem that needs to be solved in the .rpm's before the final release. I don't think any normal user will be able to find Xlib.h, or know what package to install. Red Hat was no help at all. There is no way to search their packages for a file you need, inquiries get only an automated response, and they don't appear to be doing their job on checking the stuff they pack into their releases. IDLE won't even start in Red Hat 8.0. I guess it is really up to the developers to check what Red Hat distributes. Keep up the good work. - Dave ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-20 03:00 Message: Logged In: YES user_id=676422 Neal: According to Redhat Network, my package tkinter-2.2.1-17 is installed correctly, including resolution of all dependencies. I did find XFree86-devel-4.2.0-72, and I have scheduled that for installation. I'll let you know if that solves the problem. I'm suspecting a Red Hat problem. They don't do a very good job with checking these packages. Thanks for your help. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-18 22:57 Message: Logged In: YES user_id=33168 You will need the Xlib headers installed to build Tkinter. The RPM package which contains the headers is probably something like XFree86-devel-4-3.0-2. Try installing that package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 From noreply@sourceforge.net Sat May 24 18:32:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 10:32:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19Jcsh-0006jS-00@sc8-sf-web2.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 22:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 19:32 Message: Logged In: YES user_id=21627 I missed the point that the exponent is indeed integral. Looking at the implementation, I see that it invokes __ieee754_pow, and then computes errno. If __ieee754_pow returns NaN, it sets EDOM. If anybody is interested, I attach the implementation of __ieee754_pow. I have difficulties following the code, but it appears that the detection "exponent is a natural number" uses long-long conversion. If that fails, the exponent is believed to be non-integral. I have submitted a glibc bug report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 18:08 Message: Logged In: YES user_id=31435 That's the relevant bit, yes. The subtlety is that a *is* an integer: any double with a very large exponent is an exact integer. Python checks for this by seeing whether a == floor (a); a semantically equivalent check would be to call modf (a) and see whether the fractional part returned is exactly 0.0, same-as whether the integer part returned is exactly a (which it is, for any fp # w/ a sufficiently large exponent -- unless this math library's implementation of modf is buggy too). Consider the alternative (which is what *this* platform pow appears to do): raising -1 to 1 works fine, to 1e1 works fine, to 1e2 works fine, to 1e3 works fine, to 1e4 works fine, to 1e5 works fine, ..., but at some senseless point it blows up with a domain error. As n increases, when does 10.0**n stop being "an integer"? Of course it doesn't, at least not before n is so large that 10.0**n overflows by itself. Note IEEE 754 does not view doubles as "fuzzy approximations" -- it always takes them exactly at face value, and computes the best possible result based on that. Python does this check explicitly to worm around other bugs in other libms, in order to raise ValueError when x < 0 and y is not an integer, just as the standard says. The only exception that should be possible in the cases Python passes on to the libm pow is overflow, and this platform pow () is wrong in this case. It's too hard to check for overflow a priori in a platform-independent way, and that's why we leave that part up to the platform pow(). Note that the OP is complaining about an assertion error, which means he's running a debug-build Python. I think it's thoroughly appropriate to whine about platform bugs too in a debug build. In a release build, the assert doesn't exist, and Python would raise a Python exception instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 13:55 Message: Logged In: YES user_id=21627 That error value (33) is EDOM. It seems to me that this is the correct result, according to C99 7.12.7.4p2: The pow functions compute x raised to the power y. A domain error occurs if x is finite and negative and y is finite and not an integer value. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-24 00:48 Message: Logged In: YES user_id=447507 Of course, it doesn't work, it says: errno after: 33 result: nan But my platform really isn't that special: it's the Redhat 8.0 which is a very common system! At least this should be reported to glibc (?? not sure) people. Moreover, on redhat 7.3 the python 1.5 doesn't failt this test while the python 2.0 does. It's a very standard setup (a.out is the c code you suggested) [anze@as280 anze]$ ldd a.out libm.so.6 => /lib/i686/libm.so.6 (0x4002d000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 18:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 12:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 23:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 18:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 13:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 12:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 23:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Sat May 24 18:44:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 10:44:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-739424 ] Python2.3b1 install problems on Linux Message-ID: <E19Jd4V-00068i-00@sc8-sf-web4.sourceforge.net> Bugs item #739424, was opened at 2003-05-18 05:10 Message generated for change (Comment added) made by macquigg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 Category: Build Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.3b1 install problems on Linux Initial Comment: I'm running Red Hat Linux 8.0, patches fully up to date, with the latest tcl/tk packages installed. Python2.2.1 is running fine, including Tkinter and IDLE. Followed the standard install procedure for Python-2.3.b1 tarball, and Tkinter is now broken. Can't install IDLE. ./configure and make ran OK. ~/Python-2.3b1> make test 227 tests OK 26 skipped 1 unexpected skip on linux2: test_bz2 No module named bz2 ~/Python-2.3b1> make install ... building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DWITH_APPINIT=1 -I/usr/X11R6/include -I. -I/home/macquigg/Python-2.3b1/./Include -I/usr/local/include -I/home/macquigg/Python-2.3b1/Include -I/home/macquigg/Python-2.3b1 -c /home/macquigg/Python-2.3b1/Modules/_tkinter.c -o build/temp.linux-i686-2.3/_tkinter.o cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /home/macquigg/Python-2.3b1/Modules/_tkinter.c:71: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" /usr/include/tk.h:597: parse error before "Bool" ... many more of these parse errors ... ==> Cannot find "Xlib.h" anywhere under /usr/include, /usr/X11R6, or in the Python-2.3b1 distribution. As far as I know, the X11 files have not been altered. Python 2.2.1 still runs OK. Here are the versions on the tcl/tk packages recently downloaded from RedHat. -rw-rw-r-- 1 macquigg macquigg 1570466 May 10 11:36 tcl-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 460160 May 10 13:47 tix-8.2.0b1-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 1390929 May 10 11:40 tk-8.3.3-74.i386.rpm -rw-rw-r-- 1 macquigg macquigg 265427 Apr 25 04:54 tkinter-2.2.1-17.i386.rpm More details in the attached logfile. I'll try to keep this configuration together for debugging. - Dave ---------------------------------------------------------------------- >Comment By: David MacQuigg (macquigg) Date: 2003-05-24 10:44 Message: Logged In: YES user_id=676422 Martin: You are right. This was an install from the tarball. The example I gave should not be a problem in the rpm. There are other problems with the rpm's, however, which prevent users from running IDLE. ( See the recent discussion in comp.lang.python - search "idle not working") I wish I had kept my notes, so I could be more specific about the problem I found and fixed. If you try to run IDLE from a fresh install of Red Hat 8.0 ( or 9.0 according to the post in comp.lang.python) you will see the problem. You are also right about whose responsibility these problems are. Customers are paying Red Hat to get the rpm's right. Maybe if we gave them a checklist, they would find problems like the fact that idle won't start. Let's continue this discussion in comp.lang.python. - Dave ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 10:16 Message: Logged In: YES user_id=21627 You have installed Python 2.3 from the *tarball*, right? What kind of package dependency did you expect??? Yes, packagers should be aware that they need header files to compile things. Any packager worth her money will know that, and will know how to obtain header files. On the resulting binary packages, no dependency to the header files exists: the package containing _tkinter.so only depends on the package providing libtcl.so, not on tcl-dev, and not on X11-dev. It has always been this way, and always will be; nothing has ever fallen in a crack. One might wonder why the Redhat package containing the tk header does not depend on the package containing the X11 headers, so that might be a bug in those packages. However, it would be a Redhat bug, not a Python bug. Most likely, Redhat won't consider it a bug, since you can use the Tcl/Tk headers without X11 if you are interested only in the Tcl part of that. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-24 08:52 Message: Logged In: YES user_id=676422 Martin: I'm not sure what you mean by a "system misconfiguration", and I'm concerned that this problem will occur with the final release of Python-2.3 on Red Hat Linux. My system is completely up to date with the latest Red Hat 8 patches. The missing package XFree86-devel is not one that is normally installed as part of the Red Hat standard system configuration. A dependency like this should be resolved in the packages that require it. Given the history of problems with IDLE and tkinter in Red Hat 8 and 9, it is clear to me that no testing of these modules is done on the packages that Red Hat distributes. This looks like a problem that falls in a crack between the developers and the distributors. Whoever assembles the Python-2.3 package for Red Hat should be aware of these problems. Perhaps the Python developers could put together a test script that runs IDLE, and any other module in Python-2.3 that might depend on the "system configuration". Then any time there is some change in the system, the Python packager (whoever that might be) could just run the test script, see that there is a missing "Xlib.h" or whatever, locate that file in the other packages that are part of the distribution, and add the proper dependency to the Python package. Users installing Python-2.3 will then be able to resolve these package-level dependencies as they do with any other package. I hope this is helpful, not just a nag. The new IDLE is great. I got it working with Qt Designer, and now my Python-Qt "IDE" is complete. Goodby BlackAdder. - Dave ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 05:25 Message: Logged In: YES user_id=21627 This is not a bug in Python, then, but a system misconfiguration. Closing it. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-20 10:22 Message: Logged In: YES user_id=676422 Neal: Installing XFree86-devel-4.2.0-72 and rebuilding Python-2.3b1 solved the problem. :>) Tkinter works, and so does IDLEfork-0.9a2. :>) I'm delighted with the new functionality in IDLE. Looks like I'll be giving up on BlackAdder -- *IF* I can get IDLE to play with Qt Designer. That's my next project. I'm also very impressed with Tkinter. It might just pull me away from Qt Designer. As for the currrent Tkinter install problem in 2.3b1, its just a packaging problem that needs to be solved in the .rpm's before the final release. I don't think any normal user will be able to find Xlib.h, or know what package to install. Red Hat was no help at all. There is no way to search their packages for a file you need, inquiries get only an automated response, and they don't appear to be doing their job on checking the stuff they pack into their releases. IDLE won't even start in Red Hat 8.0. I guess it is really up to the developers to check what Red Hat distributes. Keep up the good work. - Dave ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-05-19 18:00 Message: Logged In: YES user_id=676422 Neal: According to Redhat Network, my package tkinter-2.2.1-17 is installed correctly, including resolution of all dependencies. I did find XFree86-devel-4.2.0-72, and I have scheduled that for installation. I'll let you know if that solves the problem. I'm suspecting a Red Hat problem. They don't do a very good job with checking these packages. Thanks for your help. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-18 13:57 Message: Logged In: YES user_id=33168 You will need the Xlib headers installed to build Tkinter. The RPM package which contains the headers is probably something like XFree86-devel-4-3.0-2. Try installing that package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=739424&group_id=5470 From noreply@sourceforge.net Sat May 24 19:12:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 11:12:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19JdV7-0002Rf-00@sc8-sf-web1.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 16:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 14:12 Message: Logged In: YES user_id=31435 Hmm -- no attachment got attached. For contrast, check out KC Ng's implementation from fdlibm: http://www.netlib.org/fdlibm/e_pow.c In English, the line if(iy>=0x43400000) yisint = 2; /* even integer y */ says "if the true exponent is >= 53, it's an even integer", Because the implied leading 1 bit in a 754 double is to the left of the radix point, and 52 bits follow it, that's exactly right: any (finite) 754 double with a true exponent >= 53 is integral and even. If the true exponet is in [0, 52], it may or may not be integral, and if integral may be even or odd. This is still subtle, and I wish standards would spell it out more clearly. I was working on KSR's libm at the time KC Ng was working on fdlibm & corresponded with him about this stuff, and was also active in NCEG (the Numerical C Extension Group) at the time. The members of the 754 committee seemed to believe that these kinds of things were obvious to the most casual observer, and continued 754's tradition of (IMO) writing requirements in language very easy for non-754 weenies to misinterpret. I expect the glibc authors read "integer value" here as if it had something to do with C's concrete integral types. That wasn't the intent. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 13:32 Message: Logged In: YES user_id=21627 I missed the point that the exponent is indeed integral. Looking at the implementation, I see that it invokes __ieee754_pow, and then computes errno. If __ieee754_pow returns NaN, it sets EDOM. If anybody is interested, I attach the implementation of __ieee754_pow. I have difficulties following the code, but it appears that the detection "exponent is a natural number" uses long-long conversion. If that fails, the exponent is believed to be non-integral. I have submitted a glibc bug report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 12:08 Message: Logged In: YES user_id=31435 That's the relevant bit, yes. The subtlety is that a *is* an integer: any double with a very large exponent is an exact integer. Python checks for this by seeing whether a == floor (a); a semantically equivalent check would be to call modf (a) and see whether the fractional part returned is exactly 0.0, same-as whether the integer part returned is exactly a (which it is, for any fp # w/ a sufficiently large exponent -- unless this math library's implementation of modf is buggy too). Consider the alternative (which is what *this* platform pow appears to do): raising -1 to 1 works fine, to 1e1 works fine, to 1e2 works fine, to 1e3 works fine, to 1e4 works fine, to 1e5 works fine, ..., but at some senseless point it blows up with a domain error. As n increases, when does 10.0**n stop being "an integer"? Of course it doesn't, at least not before n is so large that 10.0**n overflows by itself. Note IEEE 754 does not view doubles as "fuzzy approximations" -- it always takes them exactly at face value, and computes the best possible result based on that. Python does this check explicitly to worm around other bugs in other libms, in order to raise ValueError when x < 0 and y is not an integer, just as the standard says. The only exception that should be possible in the cases Python passes on to the libm pow is overflow, and this platform pow () is wrong in this case. It's too hard to check for overflow a priori in a platform-independent way, and that's why we leave that part up to the platform pow(). Note that the OP is complaining about an assertion error, which means he's running a debug-build Python. I think it's thoroughly appropriate to whine about platform bugs too in a debug build. In a release build, the assert doesn't exist, and Python would raise a Python exception instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 07:55 Message: Logged In: YES user_id=21627 That error value (33) is EDOM. It seems to me that this is the correct result, according to C99 7.12.7.4p2: The pow functions compute x raised to the power y. A domain error occurs if x is finite and negative and y is finite and not an integer value. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 18:48 Message: Logged In: YES user_id=447507 Of course, it doesn't work, it says: errno after: 33 result: nan But my platform really isn't that special: it's the Redhat 8.0 which is a very common system! At least this should be reported to glibc (?? not sure) people. Moreover, on redhat 7.3 the python 1.5 doesn't failt this test while the python 2.0 does. It's a very standard setup (a.out is the c code you suggested) [anze@as280 anze]$ ldd a.out libm.so.6 => /lib/i686/libm.so.6 (0x4002d000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 12:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 06:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 12:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 07:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 06:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 17:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Sat May 24 21:24:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 13:24:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-742860 ] WeakKeyDictionary __delitem__ uses iterkeys Message-ID: <E19JfZ0-00078q-00@sc8-sf-web1.sourceforge.net> Bugs item #742860, was opened at 2003-05-24 16: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=742860&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Nobody/Anonymous (nobody) Summary: WeakKeyDictionary __delitem__ uses iterkeys Initial Comment: iterkeys will raise a RuntimeError if the size of the dictionary changes during iteration. Deleting items from the dictionary may cause cascade deletions which will change the dictionary size. Possible solutions: Use keys instead of iterkeys: line 155 of weakref.py: for ref in self.data.keys(): Document the possibility that __delitem__ will raise RuntimeErrors (not a preferable solution). Note that there is also a potential race condition in the __delitem__ method, where the key is del'd from the data dictionary without a try: except: to catch cases where the key is deleted between the time the key is retrieved and the time the deletion occurs (which is more likely if keys is used, but could still happen with iterkeys). Same problem is seen in both 2.2.2 and 2.2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 From noreply@sourceforge.net Sat May 24 21:26:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 13:26:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19Jfb8-0007Cp-00@sc8-sf-web1.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 16:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:26 Message: Logged In: YES user_id=31435 Wormed around in: Lib/test/test_pow.py 1.19 Misc/NEWS 1.772 Objects/floatobject.c 2.123 __,builtin__.pow() shuuld produce the correct result instead of the platform result now. math.pow() will continue to produce the platform result. If someone can test this on a failing box (test_pow.py should cover it now), please close this bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 14:12 Message: Logged In: YES user_id=31435 Hmm -- no attachment got attached. For contrast, check out KC Ng's implementation from fdlibm: http://www.netlib.org/fdlibm/e_pow.c In English, the line if(iy>=0x43400000) yisint = 2; /* even integer y */ says "if the true exponent is >= 53, it's an even integer", Because the implied leading 1 bit in a 754 double is to the left of the radix point, and 52 bits follow it, that's exactly right: any (finite) 754 double with a true exponent >= 53 is integral and even. If the true exponet is in [0, 52], it may or may not be integral, and if integral may be even or odd. This is still subtle, and I wish standards would spell it out more clearly. I was working on KSR's libm at the time KC Ng was working on fdlibm & corresponded with him about this stuff, and was also active in NCEG (the Numerical C Extension Group) at the time. The members of the 754 committee seemed to believe that these kinds of things were obvious to the most casual observer, and continued 754's tradition of (IMO) writing requirements in language very easy for non-754 weenies to misinterpret. I expect the glibc authors read "integer value" here as if it had something to do with C's concrete integral types. That wasn't the intent. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 13:32 Message: Logged In: YES user_id=21627 I missed the point that the exponent is indeed integral. Looking at the implementation, I see that it invokes __ieee754_pow, and then computes errno. If __ieee754_pow returns NaN, it sets EDOM. If anybody is interested, I attach the implementation of __ieee754_pow. I have difficulties following the code, but it appears that the detection "exponent is a natural number" uses long-long conversion. If that fails, the exponent is believed to be non-integral. I have submitted a glibc bug report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 12:08 Message: Logged In: YES user_id=31435 That's the relevant bit, yes. The subtlety is that a *is* an integer: any double with a very large exponent is an exact integer. Python checks for this by seeing whether a == floor (a); a semantically equivalent check would be to call modf (a) and see whether the fractional part returned is exactly 0.0, same-as whether the integer part returned is exactly a (which it is, for any fp # w/ a sufficiently large exponent -- unless this math library's implementation of modf is buggy too). Consider the alternative (which is what *this* platform pow appears to do): raising -1 to 1 works fine, to 1e1 works fine, to 1e2 works fine, to 1e3 works fine, to 1e4 works fine, to 1e5 works fine, ..., but at some senseless point it blows up with a domain error. As n increases, when does 10.0**n stop being "an integer"? Of course it doesn't, at least not before n is so large that 10.0**n overflows by itself. Note IEEE 754 does not view doubles as "fuzzy approximations" -- it always takes them exactly at face value, and computes the best possible result based on that. Python does this check explicitly to worm around other bugs in other libms, in order to raise ValueError when x < 0 and y is not an integer, just as the standard says. The only exception that should be possible in the cases Python passes on to the libm pow is overflow, and this platform pow () is wrong in this case. It's too hard to check for overflow a priori in a platform-independent way, and that's why we leave that part up to the platform pow(). Note that the OP is complaining about an assertion error, which means he's running a debug-build Python. I think it's thoroughly appropriate to whine about platform bugs too in a debug build. In a release build, the assert doesn't exist, and Python would raise a Python exception instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 07:55 Message: Logged In: YES user_id=21627 That error value (33) is EDOM. It seems to me that this is the correct result, according to C99 7.12.7.4p2: The pow functions compute x raised to the power y. A domain error occurs if x is finite and negative and y is finite and not an integer value. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 18:48 Message: Logged In: YES user_id=447507 Of course, it doesn't work, it says: errno after: 33 result: nan But my platform really isn't that special: it's the Redhat 8.0 which is a very common system! At least this should be reported to glibc (?? not sure) people. Moreover, on redhat 7.3 the python 1.5 doesn't failt this test while the python 2.0 does. It's a very standard setup (a.out is the c code you suggested) [anze@as280 anze]$ ldd a.out libm.so.6 => /lib/i686/libm.so.6 (0x4002d000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 12:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 06:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 12:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 07:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 06:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 17:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Sat May 24 21:48:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 13:48:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19Jfw5-0004Ci-00@sc8-sf-web3.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 16:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:48 Message: Logged In: YES user_id=31435 I'm also unclear on what the assembler is doing. I'll raise another caution about it anyway: the part after /* First see whether `y' is a natural number. In this case we can use a more precise algorithm. */ in the loop between 6 and "jnz 6b" appears to be doing exponentiation by repeated multiplication. Unless those repeated multiplies are being done in an extended precision (which they well may be -- but it depends on how the Pentium's precision-control flags are set), that's acutally less precise than a careful log+exp based approach. The latter can guarantee strictly less than 1 ulp error in the final result; multiplication using the result's precision can introduce a new 0.5 ulp with each multiply. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:26 Message: Logged In: YES user_id=31435 Wormed around in: Lib/test/test_pow.py 1.19 Misc/NEWS 1.772 Objects/floatobject.c 2.123 __,builtin__.pow() shuuld produce the correct result instead of the platform result now. math.pow() will continue to produce the platform result. If someone can test this on a failing box (test_pow.py should cover it now), please close this bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 14:12 Message: Logged In: YES user_id=31435 Hmm -- no attachment got attached. For contrast, check out KC Ng's implementation from fdlibm: http://www.netlib.org/fdlibm/e_pow.c In English, the line if(iy>=0x43400000) yisint = 2; /* even integer y */ says "if the true exponent is >= 53, it's an even integer", Because the implied leading 1 bit in a 754 double is to the left of the radix point, and 52 bits follow it, that's exactly right: any (finite) 754 double with a true exponent >= 53 is integral and even. If the true exponet is in [0, 52], it may or may not be integral, and if integral may be even or odd. This is still subtle, and I wish standards would spell it out more clearly. I was working on KSR's libm at the time KC Ng was working on fdlibm & corresponded with him about this stuff, and was also active in NCEG (the Numerical C Extension Group) at the time. The members of the 754 committee seemed to believe that these kinds of things were obvious to the most casual observer, and continued 754's tradition of (IMO) writing requirements in language very easy for non-754 weenies to misinterpret. I expect the glibc authors read "integer value" here as if it had something to do with C's concrete integral types. That wasn't the intent. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 13:32 Message: Logged In: YES user_id=21627 I missed the point that the exponent is indeed integral. Looking at the implementation, I see that it invokes __ieee754_pow, and then computes errno. If __ieee754_pow returns NaN, it sets EDOM. If anybody is interested, I attach the implementation of __ieee754_pow. I have difficulties following the code, but it appears that the detection "exponent is a natural number" uses long-long conversion. If that fails, the exponent is believed to be non-integral. I have submitted a glibc bug report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 12:08 Message: Logged In: YES user_id=31435 That's the relevant bit, yes. The subtlety is that a *is* an integer: any double with a very large exponent is an exact integer. Python checks for this by seeing whether a == floor (a); a semantically equivalent check would be to call modf (a) and see whether the fractional part returned is exactly 0.0, same-as whether the integer part returned is exactly a (which it is, for any fp # w/ a sufficiently large exponent -- unless this math library's implementation of modf is buggy too). Consider the alternative (which is what *this* platform pow appears to do): raising -1 to 1 works fine, to 1e1 works fine, to 1e2 works fine, to 1e3 works fine, to 1e4 works fine, to 1e5 works fine, ..., but at some senseless point it blows up with a domain error. As n increases, when does 10.0**n stop being "an integer"? Of course it doesn't, at least not before n is so large that 10.0**n overflows by itself. Note IEEE 754 does not view doubles as "fuzzy approximations" -- it always takes them exactly at face value, and computes the best possible result based on that. Python does this check explicitly to worm around other bugs in other libms, in order to raise ValueError when x < 0 and y is not an integer, just as the standard says. The only exception that should be possible in the cases Python passes on to the libm pow is overflow, and this platform pow () is wrong in this case. It's too hard to check for overflow a priori in a platform-independent way, and that's why we leave that part up to the platform pow(). Note that the OP is complaining about an assertion error, which means he's running a debug-build Python. I think it's thoroughly appropriate to whine about platform bugs too in a debug build. In a release build, the assert doesn't exist, and Python would raise a Python exception instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 07:55 Message: Logged In: YES user_id=21627 That error value (33) is EDOM. It seems to me that this is the correct result, according to C99 7.12.7.4p2: The pow functions compute x raised to the power y. A domain error occurs if x is finite and negative and y is finite and not an integer value. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 18:48 Message: Logged In: YES user_id=447507 Of course, it doesn't work, it says: errno after: 33 result: nan But my platform really isn't that special: it's the Redhat 8.0 which is a very common system! At least this should be reported to glibc (?? not sure) people. Moreover, on redhat 7.3 the python 1.5 doesn't failt this test while the python 2.0 does. It's a very standard setup (a.out is the c code you suggested) [anze@as280 anze]$ ldd a.out libm.so.6 => /lib/i686/libm.so.6 (0x4002d000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 12:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 06:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 12:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 07:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 06:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 17:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Sat May 24 21:50:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 13:50:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-742860 ] WeakKeyDictionary __delitem__ uses iterkeys Message-ID: <E19Jfxx-0004Gs-00@sc8-sf-web3.sourceforge.net> Bugs item #742860, was opened at 2003-05-24 16:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None >Priority: 6 Submitted By: Mike C. Fletcher (mcfletch) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakKeyDictionary __delitem__ uses iterkeys Initial Comment: iterkeys will raise a RuntimeError if the size of the dictionary changes during iteration. Deleting items from the dictionary may cause cascade deletions which will change the dictionary size. Possible solutions: Use keys instead of iterkeys: line 155 of weakref.py: for ref in self.data.keys(): Document the possibility that __delitem__ will raise RuntimeErrors (not a preferable solution). Note that there is also a potential race condition in the __delitem__ method, where the key is del'd from the data dictionary without a try: except: to catch cases where the key is deleted between the time the key is retrieved and the time the deletion occurs (which is more likely if keys is used, but could still happen with iterkeys). Same problem is seen in both 2.2.2 and 2.2.3 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:50 Message: Logged In: YES user_id=31435 Assigned to Fred (the original author, IIRC), and boosted priority a notch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 From noreply@sourceforge.net Sat May 24 23:29:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 15:29:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19JhWB-0007VW-00@sc8-sf-web3.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18: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=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Sun May 25 00:04:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 16:04:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: <E19Ji4Q-0000BV-00@sc8-sf-web3.sourceforge.net> Bugs item #705231, was opened at 2003-03-17 21:49 Message generated for change (Comment added) made by anze You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Anze Slosar (anze) Date: 2003-05-24 23:04 Message: Logged In: YES user_id=447507 >to produce the platform result. If someone can test this on >a failing box (test_pow.py should cover it now), please >close this bug. I pulled the cvs version of python and it seems to work now (see below). So, I will close this report. However, I think that the exponentiation by repeated multiplication sounds like quite a screw -up so maybe someone should report this to glibc people... Python 2.3b1+ (#1, May 24 2003, 23:56:20) [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a 1.0 >>> import math >>> b**a 1.0 >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 20:48 Message: Logged In: YES user_id=31435 I'm also unclear on what the assembler is doing. I'll raise another caution about it anyway: the part after /* First see whether `y' is a natural number. In this case we can use a more precise algorithm. */ in the loop between 6 and "jnz 6b" appears to be doing exponentiation by repeated multiplication. Unless those repeated multiplies are being done in an extended precision (which they well may be -- but it depends on how the Pentium's precision-control flags are set), that's acutally less precise than a careful log+exp based approach. The latter can guarantee strictly less than 1 ulp error in the final result; multiplication using the result's precision can introduce a new 0.5 ulp with each multiply. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 20:26 Message: Logged In: YES user_id=31435 Wormed around in: Lib/test/test_pow.py 1.19 Misc/NEWS 1.772 Objects/floatobject.c 2.123 __,builtin__.pow() shuuld produce the correct result instead of the platform result now. math.pow() will continue to produce the platform result. If someone can test this on a failing box (test_pow.py should cover it now), please close this bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 18:12 Message: Logged In: YES user_id=31435 Hmm -- no attachment got attached. For contrast, check out KC Ng's implementation from fdlibm: http://www.netlib.org/fdlibm/e_pow.c In English, the line if(iy>=0x43400000) yisint = 2; /* even integer y */ says "if the true exponent is >= 53, it's an even integer", Because the implied leading 1 bit in a 754 double is to the left of the radix point, and 52 bits follow it, that's exactly right: any (finite) 754 double with a true exponent >= 53 is integral and even. If the true exponet is in [0, 52], it may or may not be integral, and if integral may be even or odd. This is still subtle, and I wish standards would spell it out more clearly. I was working on KSR's libm at the time KC Ng was working on fdlibm & corresponded with him about this stuff, and was also active in NCEG (the Numerical C Extension Group) at the time. The members of the 754 committee seemed to believe that these kinds of things were obvious to the most casual observer, and continued 754's tradition of (IMO) writing requirements in language very easy for non-754 weenies to misinterpret. I expect the glibc authors read "integer value" here as if it had something to do with C's concrete integral types. That wasn't the intent. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 17:32 Message: Logged In: YES user_id=21627 I missed the point that the exponent is indeed integral. Looking at the implementation, I see that it invokes __ieee754_pow, and then computes errno. If __ieee754_pow returns NaN, it sets EDOM. If anybody is interested, I attach the implementation of __ieee754_pow. I have difficulties following the code, but it appears that the detection "exponent is a natural number" uses long-long conversion. If that fails, the exponent is believed to be non-integral. I have submitted a glibc bug report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:08 Message: Logged In: YES user_id=31435 That's the relevant bit, yes. The subtlety is that a *is* an integer: any double with a very large exponent is an exact integer. Python checks for this by seeing whether a == floor (a); a semantically equivalent check would be to call modf (a) and see whether the fractional part returned is exactly 0.0, same-as whether the integer part returned is exactly a (which it is, for any fp # w/ a sufficiently large exponent -- unless this math library's implementation of modf is buggy too). Consider the alternative (which is what *this* platform pow appears to do): raising -1 to 1 works fine, to 1e1 works fine, to 1e2 works fine, to 1e3 works fine, to 1e4 works fine, to 1e5 works fine, ..., but at some senseless point it blows up with a domain error. As n increases, when does 10.0**n stop being "an integer"? Of course it doesn't, at least not before n is so large that 10.0**n overflows by itself. Note IEEE 754 does not view doubles as "fuzzy approximations" -- it always takes them exactly at face value, and computes the best possible result based on that. Python does this check explicitly to worm around other bugs in other libms, in order to raise ValueError when x < 0 and y is not an integer, just as the standard says. The only exception that should be possible in the cases Python passes on to the libm pow is overflow, and this platform pow () is wrong in this case. It's too hard to check for overflow a priori in a platform-independent way, and that's why we leave that part up to the platform pow(). Note that the OP is complaining about an assertion error, which means he's running a debug-build Python. I think it's thoroughly appropriate to whine about platform bugs too in a debug build. In a release build, the assert doesn't exist, and Python would raise a Python exception instead. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 11:55 Message: Logged In: YES user_id=21627 That error value (33) is EDOM. It seems to me that this is the correct result, according to C99 7.12.7.4p2: The pow functions compute x raised to the power y. A domain error occurs if x is finite and negative and y is finite and not an integer value. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 22:48 Message: Logged In: YES user_id=447507 Of course, it doesn't work, it says: errno after: 33 result: nan But my platform really isn't that special: it's the Redhat 8.0 which is a very common system! At least this should be reported to glibc (?? not sure) people. Moreover, on redhat 7.3 the python 1.5 doesn't failt this test while the python 2.0 does. It's a very standard setup (a.out is the c code you suggested) [anze@as280 anze]$ ldd a.out libm.so.6 => /lib/i686/libm.so.6 (0x4002d000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 16:30 Message: Logged In: YES user_id=31435 Please try this C program on your box: """ #include <math.h> #include <stdio.h> #include <errno.h> int main() { double b = -1.0, a = 1.32e252; double c; errno = 0; c = pow(b, a); printf("errno after: %d\n", errno); printf("result: %g\n", c); return 0; } """ It should display this: """ errno after: 0 result: 1 """ If it doesn't display that, it's a bug in your platform math library, and should be reported to them. If we don't get reports of many platforms with this libm bug, I'm not inclined to complicate Python to work around a library bug on just one platform. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-05-23 10:08 Message: Logged In: YES user_id=447507 Here we go: [anze@as280 numbers]$ python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=1.3213112244281147e+252 >>> b=-1.0 >>> b**a python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted [anze@as280 numbers]$ Hope this helps! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 21:23 Message: Logged In: YES user_id=33168 Anze, any update on this? 2.2.3 is almost ready to go out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-21 17:20 Message: Logged In: YES user_id=31435 OK, that's some progress. We don't really have any use for a traceback -- it's clear where the code is dying. The platform pow() is setting an unexpected errno value on a call to pow(). What we need to know: 1. What were the inputs to pow()? 2. What is errno's value? We know it's not 0 and we know it's not ERANGE. I can't think of any other value that makes sense (so I'm asserting too <wink>). Note that this must be triggered by your code line: stack.append(a2**a1) so you could just print repr(a2), repr(a1) before that line, and the last output before the program dies must show the inputs the platform pow() is choking on. ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 12:43 Message: Logged In: YES user_id=447507 Crashes with python 2.2.2 as well, but seems to work under Solaris. Here's what gdb says: (gdb) [anze@APPCH numbers]> gdb `which python2` core.1406 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... Core was generated by `python2 ./makeeq.py'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/python2.2/lib-dynload/structmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/structmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/_codecsmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/_codecsmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/mathmodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so Reading symbols from /usr/lib/python2.2/lib-dynload/timemodule.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so #0 0x42029331 in kill () from /lib/i686/libc.so.6 (gdb) w Ambiguous command "w": watch, whatis, where, while, while-stepping, ws. (gdb) whe #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40030bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x42022ecb in __assert_fail () from /lib/i686/libc.so.6 #4 0x080befeb in float_pow () #5 0x080af00f in ternary_op () #6 0x080af6fc in PyNumber_Power () #7 0x08077dda in eval_frame () #8 0x0807b49c in PyEval_EvalCodeEx () #9 0x0807c4fe in fast_function () #10 0x0807a367 in eval_frame () #11 0x0807b49c in PyEval_EvalCodeEx () #12 0x0807c4fe in fast_function () #13 0x0807a367 in eval_frame () #14 0x0807b49c in PyEval_EvalCodeEx () #15 0x08077491 in PyEval_EvalCode () #16 0x080970a1 in run_node () #17 0x08096176 in PyRun_SimpleFileExFlags () #18 0x08095b9f in PyRun_AnyFileExFlags () #19 0x08053c42 in Py_Main () #20 0x08053393 in main () #21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ---------------------------------------------------------------------- Comment By: Anze Slosar (anze) Date: 2003-03-20 11:14 Message: Logged In: YES user_id=447507 Operating system is RedHat 8.0 with custom 2.4.20 kernel. I did the following: [anze@as280 anze]$ ldd `which python` libdl.so.2 => /lib/libdl.so.2 (0x4002d000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40031000) libutil.so.1 => /lib/libutil.so.1 (0x40061000) libm.so.6 => /lib/i686/libm.so.6 (0x40064000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6 glibc-2.2.93-5 [anze@as280 anze]$ So it seems to me that libm is from glibc-2.2.93-5. Compiler is stock redhat gcc-3.2, but I haven't compiled anything myself... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-17 22:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Sun May 25 00:31:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 16:31:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19JiUU-0004cc-00@sc8-sf-web1.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Sun May 25 00:40:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 16:40:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current Message-ID: <E19Jicv-0004pr-00@sc8-sf-web1.sourceforge.net> Bugs item #740234, was opened at 2003-05-19 23:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Till Plewe (tpx) Assigned to: Nobody/Anonymous (nobody) Summary: test/build-failures on FreeBSD stable/current Initial Comment: Using snapshot: python_2003-05-19_230000.tar.gz STABLE (FreeBSD 4.8-STABLE #14: Mon Apr 7) CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue May 20) BUILDFAILURE curses does not build; neither on CURRENT nor on STABLE (compiler complaint: /usr/include/ncurses.h:289: conflicting types for `wchar_t' /usr/include/stdlib.h:57: previous declaration of `wchar_t' /usr/include/ncurses.h:292: conflicting types for `wint_t' /usr/include/wchar.h:96: previous declaration of `wint_t' if lines /usr/include/ncurses.h:288-293 #ifndef __wchar_t typedef unsigned long wchar_t; #endif /* __wchar_t */ #ifndef __wint_t typedef long int wint_t; #endif /* __wint_t */ are deleted then curses builds) TESTFAILURES test_re fails on both CURRENT and STABLE test_long test_pow and many more (probably related) tests fail on current See attached file for details ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:40 Message: Logged In: YES user_id=33168 Can you determine what the conflict in the header files which prevents curses from building? My guess is that test_bug_418626() is causing the core dump (from test_re.py). Can you verify the problem is in that function? If so, can you test each of the re.match/re.search in the interpreter to determine which line is failling? My guess is that it's related to the recursion limit (likely the last line). Your stack size limit may be too small for the python recursion limit. You can try doing a ulimit -a to see all the limits. ulimit -s 8192 is what my stack size is set to (but on Linux). Doing that command may work for you. But this is all conjecture until you investigate further. ---------------------------------------------------------------------- Comment By: Till Plewe (tpx) Date: 2003-05-22 01:04 Message: Logged In: YES user_id=782552 Most of the test failures on FreeBSD CURRENT seem to be gcc bugs. (I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release)) Rebuilding world with the additional compiler flag -mno-sse2 got rid of most test failures. Now only the curses build failure and the test_re failure remain. ---------------------------------------------------------------------- Comment By: Till Plewe (tpx) Date: 2003-05-22 00:57 Message: Logged In: YES user_id=782552 I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release). Most of the test failures seem to be gcc-bugs. Rebuilding world with the extra compiler flag -mno-sse2 got rid of most test failures. Now only the test_re failure and the curses build failure remain. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 18:34 Message: Logged In: YES user_id=33168 I think many of the failures are due to the test_long failure. If that problem is fixed, my guess is several other tests will start working. What compiler are you using? Can you try to debug the test_long failure? I don't think any python developers have access to a freebsd box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 From noreply@sourceforge.net Sun May 25 01:36:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 17:36:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-742860 ] WeakKeyDictionary __delitem__ uses iterkeys Message-ID: <E19JjV8-0003mZ-00@sc8-sf-web2.sourceforge.net> Bugs item #742860, was opened at 2003-05-24 16:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakKeyDictionary __delitem__ uses iterkeys Initial Comment: iterkeys will raise a RuntimeError if the size of the dictionary changes during iteration. Deleting items from the dictionary may cause cascade deletions which will change the dictionary size. Possible solutions: Use keys instead of iterkeys: line 155 of weakref.py: for ref in self.data.keys(): Document the possibility that __delitem__ will raise RuntimeErrors (not a preferable solution). Note that there is also a potential race condition in the __delitem__ method, where the key is del'd from the data dictionary without a try: except: to catch cases where the key is deleted between the time the key is retrieved and the time the deletion occurs (which is more likely if keys is used, but could still happen with iterkeys). Same problem is seen in both 2.2.2 and 2.2.3 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 20:36 Message: Logged In: YES user_id=31435 In staring at the code, I'm baffled as to why __delitem__ iterates over the keys at all. Why isn't the implementation the one-liner del self.data[ref(key)] ? That's basically what __contains__, has_key() and __getitem__ get away with. Two refs to the same object have the same hash codes and compare equal, so I'm having a hard time seeing why that isn't good enough for __delitem__ too. Mike, I didn't understand your point about the race condition. The object passed to __delitem__ as the key has a strong reference to it merely by virtue of having been passed to __delitem__, so it can't go away until (at earliest) __delitem__ returns (and so drops its strong reference to key). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:50 Message: Logged In: YES user_id=31435 Assigned to Fred (the original author, IIRC), and boosted priority a notch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 From noreply@sourceforge.net Sun May 25 01:58:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 17:58:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-742860 ] WeakKeyDictionary __delitem__ uses iterkeys Message-ID: <E19Jjq3-0007CN-00@sc8-sf-web1.sourceforge.net> Bugs item #742860, was opened at 2003-05-24 16:24 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakKeyDictionary __delitem__ uses iterkeys Initial Comment: iterkeys will raise a RuntimeError if the size of the dictionary changes during iteration. Deleting items from the dictionary may cause cascade deletions which will change the dictionary size. Possible solutions: Use keys instead of iterkeys: line 155 of weakref.py: for ref in self.data.keys(): Document the possibility that __delitem__ will raise RuntimeErrors (not a preferable solution). Note that there is also a potential race condition in the __delitem__ method, where the key is del'd from the data dictionary without a try: except: to catch cases where the key is deleted between the time the key is retrieved and the time the deletion occurs (which is more likely if keys is used, but could still happen with iterkeys). Same problem is seen in both 2.2.2 and 2.2.3 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-24 20:58 Message: Logged In: YES user_id=34901 Re: race condition. Thread 1 calls del d[x] and then thread 2 calls del d[x]. Both have strong refs to the key, so the weakrefs don't die, both get the list of keys (weakrefs) to scan before either deletes a key, both then try to delete the item from the data dictionary. That is: t1: del d[x] t2: del d[x] t1: gets keys() t2: gets keys() t1: finds key in keys, does del data[ref] t2: finds key in keys (even though it's no longer in the dictionary), tries to do del data[ref], raises KeyError because t1 has already removed the weakref key from the data dictionary. I may be wrong, of course. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 20:36 Message: Logged In: YES user_id=31435 In staring at the code, I'm baffled as to why __delitem__ iterates over the keys at all. Why isn't the implementation the one-liner del self.data[ref(key)] ? That's basically what __contains__, has_key() and __getitem__ get away with. Two refs to the same object have the same hash codes and compare equal, so I'm having a hard time seeing why that isn't good enough for __delitem__ too. Mike, I didn't understand your point about the race condition. The object passed to __delitem__ as the key has a strong reference to it merely by virtue of having been passed to __delitem__, so it can't go away until (at earliest) __delitem__ returns (and so drops its strong reference to key). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:50 Message: Logged In: YES user_id=31435 Assigned to Fred (the original author, IIRC), and boosted priority a notch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 From noreply@sourceforge.net Sun May 25 02:30:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 18:30:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-742860 ] WeakKeyDictionary __delitem__ uses iterkeys Message-ID: <E19JkKv-0001Bx-00@sc8-sf-web4.sourceforge.net> Bugs item #742860, was opened at 2003-05-24 16:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakKeyDictionary __delitem__ uses iterkeys Initial Comment: iterkeys will raise a RuntimeError if the size of the dictionary changes during iteration. Deleting items from the dictionary may cause cascade deletions which will change the dictionary size. Possible solutions: Use keys instead of iterkeys: line 155 of weakref.py: for ref in self.data.keys(): Document the possibility that __delitem__ will raise RuntimeErrors (not a preferable solution). Note that there is also a potential race condition in the __delitem__ method, where the key is del'd from the data dictionary without a try: except: to catch cases where the key is deleted between the time the key is retrieved and the time the deletion occurs (which is more likely if keys is used, but could still happen with iterkeys). Same problem is seen in both 2.2.2 and 2.2.3 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 21:30 Message: Logged In: YES user_id=31435 Ah, threads. OK, but if two threads both try to delete the same key, then one of them *should* see a KeyError -- same as for a regular dict. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-24 20:58 Message: Logged In: YES user_id=34901 Re: race condition. Thread 1 calls del d[x] and then thread 2 calls del d[x]. Both have strong refs to the key, so the weakrefs don't die, both get the list of keys (weakrefs) to scan before either deletes a key, both then try to delete the item from the data dictionary. That is: t1: del d[x] t2: del d[x] t1: gets keys() t2: gets keys() t1: finds key in keys, does del data[ref] t2: finds key in keys (even though it's no longer in the dictionary), tries to do del data[ref], raises KeyError because t1 has already removed the weakref key from the data dictionary. I may be wrong, of course. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 20:36 Message: Logged In: YES user_id=31435 In staring at the code, I'm baffled as to why __delitem__ iterates over the keys at all. Why isn't the implementation the one-liner del self.data[ref(key)] ? That's basically what __contains__, has_key() and __getitem__ get away with. Two refs to the same object have the same hash codes and compare equal, so I'm having a hard time seeing why that isn't good enough for __delitem__ too. Mike, I didn't understand your point about the race condition. The object passed to __delitem__ as the key has a strong reference to it merely by virtue of having been passed to __delitem__, so it can't go away until (at earliest) __delitem__ returns (and so drops its strong reference to key). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:50 Message: Logged In: YES user_id=31435 Assigned to Fred (the original author, IIRC), and boosted priority a notch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 From noreply@sourceforge.net Sun May 25 02:47:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 18:47:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-742860 ] WeakKeyDictionary __delitem__ uses iterkeys Message-ID: <E19Jkbk-0005vS-00@sc8-sf-web2.sourceforge.net> Bugs item #742860, was opened at 2003-05-24 16:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakKeyDictionary __delitem__ uses iterkeys Initial Comment: iterkeys will raise a RuntimeError if the size of the dictionary changes during iteration. Deleting items from the dictionary may cause cascade deletions which will change the dictionary size. Possible solutions: Use keys instead of iterkeys: line 155 of weakref.py: for ref in self.data.keys(): Document the possibility that __delitem__ will raise RuntimeErrors (not a preferable solution). Note that there is also a potential race condition in the __delitem__ method, where the key is del'd from the data dictionary without a try: except: to catch cases where the key is deleted between the time the key is retrieved and the time the deletion occurs (which is more likely if keys is used, but could still happen with iterkeys). Same problem is seen in both 2.2.2 and 2.2.3 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 21:47 Message: Logged In: YES user_id=31435 Mike, can you try current CVS Python (2.3)? Fred won't be back for days, so I can't quiz him. I implemented the one- liner __delitem__, which is much faster, can't raise RuntimeError, and should be better behaved in all respects in the face of threads and/or comparison functions that mutate the dict as a side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 21:30 Message: Logged In: YES user_id=31435 Ah, threads. OK, but if two threads both try to delete the same key, then one of them *should* see a KeyError -- same as for a regular dict. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-24 20:58 Message: Logged In: YES user_id=34901 Re: race condition. Thread 1 calls del d[x] and then thread 2 calls del d[x]. Both have strong refs to the key, so the weakrefs don't die, both get the list of keys (weakrefs) to scan before either deletes a key, both then try to delete the item from the data dictionary. That is: t1: del d[x] t2: del d[x] t1: gets keys() t2: gets keys() t1: finds key in keys, does del data[ref] t2: finds key in keys (even though it's no longer in the dictionary), tries to do del data[ref], raises KeyError because t1 has already removed the weakref key from the data dictionary. I may be wrong, of course. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 20:36 Message: Logged In: YES user_id=31435 In staring at the code, I'm baffled as to why __delitem__ iterates over the keys at all. Why isn't the implementation the one-liner del self.data[ref(key)] ? That's basically what __contains__, has_key() and __getitem__ get away with. Two refs to the same object have the same hash codes and compare equal, so I'm having a hard time seeing why that isn't good enough for __delitem__ too. Mike, I didn't understand your point about the race condition. The object passed to __delitem__ as the key has a strong reference to it merely by virtue of having been passed to __delitem__, so it can't go away until (at earliest) __delitem__ returns (and so drops its strong reference to key). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:50 Message: Logged In: YES user_id=31435 Assigned to Fred (the original author, IIRC), and boosted priority a notch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 From noreply@sourceforge.net Sun May 25 02:56:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 18:56:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-727241 ] Core Dumps : Python2.2.2 Message-ID: <E19Jkks-00069M-00@sc8-sf-web2.sourceforge.net> Bugs item #727241, was opened at 2003-04-24 18:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470 Category: None Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eli Rosenberg (elirosenberg) Assigned to: Nobody/Anonymous (nobody) Summary: Core Dumps : Python2.2.2 Initial Comment: Hello, I am able to cause python to core dump on IRIX 6.5.18 and above with the code listed below. I have compiled with 3 versions of gcc as well as MIPSpro. Running this code with a valid host and a port that will cause a connection refused socket error produces a core dump with the the stack trace below. >>> import socket >>> x=socket.socket() >>> x.connect(('www.google.com', 1234)) > 0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527, 0xfb245fc] 1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945, 0xfb24e44] 2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230, 0xfb24078] 3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186, 0xfb23ee4] 4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868, 0x10092244] 5 _PyObject_GC_New(tp = 0x1013fbe0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895, 0x10092368] 6 newtracebackobject(next = (nil), frame = 0x1016b670, lasti = 21, lineno = 1) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":115, 0x100c6684] 7 PyTraceBack_Here(frame = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":133, 0x100c67f4] 8 eval_frame(f = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238, 0x1004e894] 9 PyEval_EvalCodeEx(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount = 0, kws = (nil), kwcount = 0, defs = (nil), defcount = 0, closure = (nil)) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595, 0x1004ffe0 10 PyEval_EvalCode(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":481, 0x10047ea0] 11 run_node(n = 0x101a5b28, filename = 0x1014e978 = "<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079, 0x1006f380] 12 PyRun_InteractiveOneFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590, 0x1006d57c] 13 PyRun_InteractiveLoopFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526, 0x1006d198] 14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", closeit = 0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489, 0x1006cf48] 15 Py_Main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/main.c":364, 0x1000fa44] 16 main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/python.c":10, 0x1000ecdc] 17 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1000ec78] I compiled Python 64-bit and the code above appears not to cause a segfault but the code below will bus error after a few iterations. import socket import time def doit(): s = socket.socket() start = time.time() try: s.connect(('www.cnn.com', 80)) except socket.error,e: print repr(e),str(e) finish = time.time() time.sleep(.5) print str(finish-start),"\n" s.close() for x in xrange(10): doit() Here is the stack trace: > 0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527, 0xfb245fc] 1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945, 0xfb24e44] 2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230, 0xfb24078] 3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186, 0xfb23ee4] 4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868, 0x10092244] 5 _PyObject_GC_New(tp = 0x1013fbe0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895, 0x10092368] 6 newtracebackobject(next = (nil), frame = 0x1016b670, lasti = 21, lineno = 1) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":115, 0x100c6684] 7 PyTraceBack_Here(frame = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":133, 0x100c67f4] 8 eval_frame(f = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238, 0x1004e894] 9 PyEval_EvalCodeEx(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount = 0, kws = (nil), kwcount = 0, defs = (nil), defcount = 0, closure = (nil)) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595, 0x1004ffe0 10 PyEval_EvalCode(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":481, 0x10047ea0] 11 run_node(n = 0x101a5b28, filename = 0x1014e978 = "<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079, 0x1006f380] 12 PyRun_InteractiveOneFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590, 0x1006d57c] 13 PyRun_InteractiveLoopFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526, 0x1006d198] 14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", closeit = 0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489, 0x1006cf48] 15 Py_Main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/main.c":364, 0x1000fa44] 16 main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/python.c":10, 0x1000ecdc] 17 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1000ec78] Any help would be appreciated. thanks. -Eli ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 21:56 Message: Logged In: YES user_id=33168 I can't reproduce this problem with 2.2.3 on Irix 6.5: % uname -a IRIX rattler 6.5 10120734 IP32 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-04-25 15:03 Message: Logged In: YES user_id=21627 No. Except for MacOS, there is are no port maintainers. There are experts for some of the Unices, but only for Linux and Solaris. For things as strange as Irix, we have to have actual users of the systems to fully understand the problem and provide patches. In general, we accept work-arounds only if it can be shown that a work-around is necessary around a true platform bug (see how the getaddrinfo emulation is used on OSX, even though the platform provides a native implementation). I'm pretty certain that Python's usage of the getaddrinfo API is correct. If this is still causing crashes, it may be that the implementation in the Irix library is buggy. Have you applied all vendor patches? ---------------------------------------------------------------------- Comment By: Eli Rosenberg (elirosenberg) Date: 2003-04-25 14:28 Message: Logged In: YES user_id=764663 Hmm, I don't know for sure, but closing might not be the best idea because anyone else building on a really recent IRIX will have problems with socketmodule. Is there an IRIX maintainer or somebody like that? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-25 14:06 Message: Logged In: YES user_id=6656 so... do you think the fault is with Python or IRIX? if you're happy enough with the situation as it stands, we may as well close this... ---------------------------------------------------------------------- Comment By: Eli Rosenberg (elirosenberg) Date: 2003-04-25 13:41 Message: Logged In: YES user_id=764663 Hi, I think I have fixed things...for now. Here is what I see: IRIX now includes POSIX 1003.1g draft implementations of getaddrinfo/getnameinfo in accordance with http://www.ietf.org/proceedings/01mar/I-D/ipngwg-rfc2553bis-03.txt Previously, netdb.h on IRIX did not have these definitions and Python compiled in its own implementations and things seemed to work. I changed pyconfig.h to have socketmodule use its own implementations, but I did have to make a few changes because the IRIX prototypes for these functions are for the 2001 version of the standards, whereas socketmodule seemed to have 1999 versions from RFC2553. Not knowing much about the Python C API, I did not look closely enough to see why socketmodule seems to cause memory faults when compiled with the IRIX libc versions of these functions. Hopefully this is the source of the problem. -eli ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-25 06:53 Message: Logged In: YES user_id=6656 This looks nasty... Could you try making a debug build of Python (pass --with-pydebug to ./configure) and/or try with current CVS? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470 From noreply@sourceforge.net Sun May 25 03:42:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 19:42:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-701936 ] getsockopt/setsockopt with SO_RCVTIMEO are inconsistent Message-ID: <E19JlSy-0002lu-00@sc8-sf-web4.sourceforge.net> Bugs item #701936, was opened at 2003-03-11 21:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701936&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: getsockopt/setsockopt with SO_RCVTIMEO are inconsistent Initial Comment: The SO_RCVTIMEO option to getsockopt/setsockopt seems to vary it's parameter format when used under Linux. With setsockopt, the parameter seems to be a struct of {long seconds, long microseconds}, as you would expect since it's modelling a C "struct timeval". However, with getsockopt, the parameter format seems to be {long seconds, long milliseconds} --- ie. it uses milliseconds rather than microseconds. The attached python script demonstrates this problem. Am I doing something crucially wrong, or is this meant to happen, or ... ? What I'm using: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 22:42 Message: Logged In: YES user_id=33168 I just tested this on my box (Redhat 9/Linux 2.4). I get similar results with a C program as Python. (Not sure why I didn't get exactly the same results, but I'm tired.) So I'm not sure Python has a problem, since it is just exposing what is happening in C. Take a look at the C example and try it on your box. What results do you get? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701936&group_id=5470 From noreply@sourceforge.net Sun May 25 03:47:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 19:47:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i Message-ID: <E19JlXy-0001uK-00@sc8-sf-web1.sourceforge.net> Bugs item #694431, was opened at 2003-02-27 10:44 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.3a2 Build fails on HP-UX11i Initial Comment: While building Python 2.3a2 on HP-UX11i I got the following error: ld -b build/temp.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.o -L/opt/python/lib - L/usr/local/lib -o build/lib.hp-ux-B.11.11- 9000/785-2.3/_iconv_codec.sl /usr/lib/dld.sl: Unresolved symbol: libiconv_open (code) from build/lib.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.sl sh[3]: 25624 Abort(coredump) *** Error exit code 134 ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-05-24 10:25 Message: Logged In: YES user_id=200117 Neal, since iconv was removed I can build Python 2.3 OK, therfore I'm happy for the bug report to be closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:48 Message: Logged In: YES user_id=33168 Richard, is this still a problem? iconv has been removed. Should this bug be closed? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-31 02:36 Message: Logged In: YES user_id=200117 Yes, I was just trying to get Python to compile. I'm not aware that we have any need for the iconv codec module. What is the best way to get the build process to omit it from the build? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 16:55 Message: Logged In: YES user_id=33168 This means the iconv_open() call is failing. Unless you know you need this module, you probably don't. And if you do need this module, you probably know more than I do. :-) So if you are just trying to get this working, I don't think it's a big deal. It seems to work on some HPUX machines. I suspect the reason the iconv_open() is failing is because of a configuration on your machine. This call is for translating character sets. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-26 11:26 Message: Logged In: YES user_id=200117 Hi Neal, I edited Modules/Setup line 483 like this: _iconv_codec _iconv_codec.c -I/usr/include I can now build Python! However test_iconv_codecs fails: capulet:dist/src > ./python ./Lib/test/test_iconv_codecs.py Traceback (most recent call last): File "./Lib/test/test_iconv_codecs.py", line 3, in ? import codecs, _iconv_codec RuntimeError: can't initialize the _iconv_codec module: iconv_open() failed I tried adding '-l:libdld.sl' to line 483 (as suggested by the man page) but the test still fails. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-26 09:43 Message: Logged In: YES user_id=200117 Hi Neal, I have now discovered that there is a different version of iconv.h on my workstation in /usr/local/include. It appears to be part of the zlib package and it contains the pre-processor macros which are converting the iconv statements to libiconv. It is being used instead of the one in /usr/include, because the compile command contains -I/usr/local/include Is there any easy to prevent this path from being added to the compile commands? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-25 12:51 Message: Logged In: YES user_id=200117 Neal, The original error referred to unresolved symbol 'libiconv_open'. The source module _iconv_codec.c contains calls to iconv_open(), not libiconv_open(). However, if I recompile it with the -E flag there is a pre- processor substitution happening which is converting all instances of 'iconv' to 'libiconv' Here I grepped the pre-processor output for 'iconv'... extern int _libiconv_version; typedef void* libiconv_t ; extern libiconv_t libiconv_open (const char* tocode, const char* fromcode); extern size_t libiconv (libiconv_t cd, char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); extern int libiconv_close (libiconv_t cd); extern int libiconvctl (libiconv_t cd, int request, void* argument); libiconv_t enchdl, dechdl; if (libiconv (self->enchdl, (char**)&inp, &inplen, &out, &outlen) size_t res = libiconv (self->dechdl, (char**)&inp, &inplen, &out, &outlen); new->enchdl = new->dechdl = (libiconv_t )(-1); new->dechdl = libiconv_open ("ucs-2-internal" , new->encoding); if (new->dechdl == (libiconv_t )(-1)) { new->enchdl = libiconv_open (new->encoding, "ucs- 2-internal" ); if (new->enchdl == (libiconv_t )(-1)) { libiconv_close (new->dechdl); new->dechdl = (libiconv_t )(-1); if (self->enchdl != (libiconv_t )-1) libiconv_close (self->enchdl); if (self->dechdl != (libiconv_t )-1) libiconv_close (self->dechdl); libiconv_t hdl = libiconv_open ("ucs-2- internal" , "ISO-8859-1"); if (hdl == (libiconv_t )-1) { res = libiconv (hdl, &inptr, &insize, &outptr, &outsize); libiconv_close (hdl); libiconv_close (hdl); Is this supposed to be happening?? If not, what could be causing it?? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:52 Message: Logged In: YES user_id=33168 Looking further into the python configure, I see that the option is --with-dl-dld, however, this option is not supported. Can try to play with the build options to find the magic that works on your version of HPUX? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 10:48 Message: Logged In: YES user_id=33168 Richard, in the manpage it says that iconv has a dependancy on libdld.sl. Perhaps you need to configure python --with-dld. Can you try that? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-04 12:09 Message: Logged In: YES user_id=200117 Neal, I will try to help, but internet access is difficult at work so responses may not be prompt. I had a look at the man page but it was not clear to me which library contains iconv_open. I will attach text copy of the man page for you. I also include some nm output from libc.sl which refers to iconv_open, but I'm not sure if it means that it contains the code for the function. Let me know if I can try anything else. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:15 Message: Logged In: YES user_id=33168 Richard, can you help diagnose further since I can't reproduce on HP-UX 11.00? My initial guess is that iconv_open is in a different location, therefore the linking is faililng. Does man iconv_open reveal what library iconv_open is in? To add directories, etc. to the build/link of iconv, you will need to edit setup.py (or test on the command line). Check around line 620 in setup.py. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-03 04:14 Message: Logged In: YES user_id=200117 Sorry for the delay but I had to download from CVS at home yesterday (Sunday 2nd) and build on HP-UX at work today. Unfortunately I'm still getting the same linker error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 12:37 Message: Logged In: YES user_id=33168 This iconv_codec problem may be fixed. Please test with current CVS to verify. See SF bug #690012. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-27 22:45 Message: Logged In: YES user_id=33168 Richard, can you try the latest version from CVS. I don't have this problem on hp-ux-B.11.00-9000/829 I do have a problem with readline, but I think that's specific to the machine I'm building on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 From noreply@sourceforge.net Sun May 25 03:53:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 19:53:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19Jldf-00037N-00@sc8-sf-web4.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Sun May 25 05:49:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 21:49:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19JnSC-00023W-00@sc8-sf-web3.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) >Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-25 00:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Sun May 25 09:03:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 01:03:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-663782 ] test_socket test_unicode_file fail on 2.3a1 on winNT Message-ID: <E19JqTg-00080j-00@sc8-sf-web2.sourceforge.net> Bugs item #663782, was opened at 2003-01-07 17:58 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_socket test_unicode_file fail on 2.3a1 on winNT Initial Comment: This happens after installing 2.3a1 on winNT 4 sp6. D:\apps\Python23>python D:\apps\Python23\Lib\test\test_socket.py testCrucialConstants (__main__.GeneralModuleTests) ... ok testDefaultTimeout (__main__.GeneralModuleTests) ... ok testGetServByName (__main__.GeneralModuleTests) ... ok testGetSockOpt (__main__.GeneralModuleTests) ... ok testHostnameRes (__main__.GeneralModuleTests) ... ok testInterpreterCrash (__main__.GeneralModuleTests) ... ok testNtoH (__main__.GeneralModuleTests) ... ok testRefCountGetNameInfo (__main__.GeneralModuleTests) ... ok testSendAfterClose (__main__.GeneralModuleTests) ... ok testSetSockOpt (__main__.GeneralModuleTests) ... ok testSockName (__main__.GeneralModuleTests) ... ok testSocketError (__main__.GeneralModuleTests) ... ok testFromFd (__main__.BasicTCPTest) ... ok testOverFlowRecv (__main__.BasicTCPTest) ... ok testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok testRecv (__main__.BasicTCPTest) ... ok testRecvFrom (__main__.BasicTCPTest) ... ok testSendAll (__main__.BasicTCPTest) ... ok testShutdown (__main__.BasicTCPTest) ... ok testRecvFrom (__main__.BasicUDPTest) ... ok testSendtoAndRecv (__main__.BasicUDPTest) ... ok testAccept (__main__.NonBlockingTCPTests) ... FAIL ERROR testConnect (__main__.NonBlockingTCPTests) ... ok testRecv (__main__.NonBlockingTCPTests) ... ok testSetBlocking (__main__.NonBlockingTCPTests) ... ok testFullRead (__main__.FileObjectClassTestCase) ... ok testReadline (__main__.FileObjectClassTestCase) ... ok testSmallRead (__main__.FileObjectClassTestCase) ... ok testUnbufferedRead (__main__.FileObjectClassTestCase) ... ok testFullRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testUnbufferedReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok testFullRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testReadline (__main__.LineBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testFullRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testReadline (__main__.SmallBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok ====================================================================== ERROR: testAccept (__main__.NonBlockingTCPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 117, in _tearDown self.fail(msg) File "D:\apps\Python23\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: (10061, 'Connection refused') ====================================================================== FAIL: testAccept (__main__.NonBlockingTCPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 475, in testAccept self.fail("Error trying to do non-blocking accept.") File "D:\apps\Python23\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: Error trying to do non-blocking accept. ---------------------------------------------------------------------- Ran 42 tests in 2.204s FAILED (failures=1, errors=1) Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 632, in ? test_main() File "D:\apps\Python23\Lib\test\test_socket.py", line 629, in test_main test_support.run_suite(suite) File "D:\apps\Python23\lib\test\test_support.py", line 217, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details D:\apps\Python23>python D:\apps\Python23\Lib\test\test_unicode_file.py File doesn't exist (encoded string) after creating it Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_unicode_file.py", line 37, in ? if os.stat(TESTFN_ENCODED) != os.stat(TESTFN_UNICODE): OSError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2003-05-25 11:03 Message: Logged In: YES user_id=358087 As far as I recall it does. (I've lost my job so I don't have access to NT anymore). Miki ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-23 00:55 Message: Logged In: YES user_id=33168 Miki, are you still having this problem with 2.3b1? Can this be closed? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2003-04-26 20:14 Message: Logged In: YES user_id=129426 Both tests run fine on my windows XP box with Python 2.3b... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-25 06:03 Message: Logged In: YES user_id=31435 I personally tested these before the releases, on Win98SE and on Win2000 Pro. No problems there, although test_unicode_file turns itself off on Win9x. I don't have access to an NT box, and these won't get fixed until a Python developer who does have NT can dig into them there. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-03-24 09:51 Message: Logged In: YES user_id=358087 Yes. Version is: 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC v.1200 32 bit (Intel)] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 22:40 Message: Logged In: YES user_id=33168 Is this problem still happening with 2.3a2+ ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470 From noreply@sourceforge.net Sun May 25 14:21:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 06:21:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball Message-ID: <E19JvRP-0003N5-00@sc8-sf-web2.sourceforge.net> Bugs item #728051, was opened at 2003-04-26 14:23 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Neal Norwitz (nnorwitz) Summary: Test failures on Linux, Python 2.3b1 tarball Initial Comment: "make test" resulted in: test test_tempfile failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test test_time failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/Python-2.3b1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2003-05-25 13:21 Message: Logged In: YES user_id=56214 Here's the tz info; I'll email you the 'man tzset' separately. [admin@pilot Python-2.3a1]$ ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EST') -36000 -39600 [admin@pilot Python-2.3a1]$ cd ../Python-2.3b1 [admin@pilot Python-2.3b1]$ ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EST') -36000 -39600 [ ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-05-22 00:41 Message: Logged In: YES user_id=46639 This is from my patch. Phillip - can you please upload a copy of 'man tzset' on that Redhat box or email it to zen@shangri-la.dropbear.id.au. I'd also like to see the output of: python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='US/Eastern' \ python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='Australia/Melbourne' \ python -c 'import time;print time.tzname,time.timezone,time.altzone' I'm thinking that tzset(3) and the time libraries are not fully functional on this earlier version of Redhat, possibly by not handling southern hemisphere daylight savings. If so, it needs to be detected during configuration. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 15:00 Message: Logged In: YES user_id=21627 Neal, it appears you have checked in the test for the AEST zone. Can you analyse the test_time failure in more detail? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-04 13:19 Message: Logged In: YES user_id=56214 It's an ISP-supplied variant of RedHat 6.2. I see 'libc-2.1.3.so' in the /lib directory, so I assume that's the version. Running 'strings' on it, I find: GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Python identifies itself as: Python 2.3b1 (#1, Apr 26 2003, 10:02:40) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 I just tested 2.3a1 andr 2.3a2 to confirm where the errors began. 2.3a1 doesn't show either error. 2.3a2 has the tempfile problem, but not the time problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 12:42 Message: Logged In: YES user_id=21627 What operating system distribution specifically did you use? What C library does this system use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 From noreply@sourceforge.net Sun May 25 14:40:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 06:40:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-723540 ] __slots__ broken in 2.3a with ("__dict__", ) Message-ID: <E19Jvjj-0002MW-00@sc8-sf-web3.sourceforge.net> Bugs item #723540, was opened at 2003-04-18 07:35 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: __slots__ broken in 2.3a with ("__dict__", ) Initial Comment: I LOVE using __slots__. I love using properties. I made my own extension and metaclass so I could define type safe properties in classes. I could stick properties on a class and have them accessed seperatly from slots (because they are properties and not attributes). The properties call setter/getters and store the data in __dict__ (a cheezy means of making pickle still work with no effort). thus I had __slots__ = ('__dict__', ) in my base class. this worked great in 2.2 and 2.2.2. Im migrating all my modules to 2.3. I just fixed a bug in my code that was due to a typo. Thats when I realized that __slots__ was no longer working in 2.3a. I cant find anything on this change in behavior. if slots contains "__dict__" slots is turned OFF!!! simplified version of the bug: $ python Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... __slots__ = ("__dict__", ) ... >>> a = foo() >>> a.bad = 3 Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'foo' object has no attribute 'bad' >>> ^Z $ python23 Python 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... __slots__ = ("__dict__", ) ... >>> a = foo() >>> a.bad = 3 >>> dir(a) ['__class__', '__delattr__', '__dict__', '__doc__', '__getattr ibute__', '__hash_ _', '__init__', '__module__', '__new__', '__reduce__', '__re duce_ex__', '__repr_ _', '__setattr__', '__slots__', '__str__', 'bad'] >>> ^Z ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-25 13:40 Message: Logged In: YES user_id=56214 >From discussion on Python-Dev, this behavior is a feature, not a bug. Or to be precise, the 2.2 behavior of __slots__ is a bug, or at least a misfeature. If an object has a __dict__, it is supposed to allow setting arbitrary attributes. The behavior was fixed in 2.3 (see http://www.python.org/2.2.3/descrintro.html). A backward-compatible solution to your problem is to create a slot with a different name than __dict__, store a dictionary in it, and add __setstate__/__getstate__ methods to your base class that operate on it. This should work correctly for both 2.2 and 2.3, and preserve the fixed namespace behavior you're looking for, as long as all subclasses set __slots__ to an empty list. (You can always have your metaclass do that in its __new__ method, if you don't want to have to remember to do it manually. Just be sure not to overwrite __slots__ if present, since your base class will need to set up the slot for the "hidden" dictionary.) Hmm. I just read all the followups in more detail and noticed you are already using a __fakedict__ slot, but refer to the pickle handling as "yuck"; note that this: class MyBase(object): __slots__ = '__fakedict__' def __getstate__(self): return self.__fakedict__ def __setstate__(self,state): self.__fakedict__ = state ...should be all you need to get pickling working correctly under 2.2, assuming that you already have an __init__ that sets __fakedict__ to a dictionary. Since in 2.2, a __dict__ slot was not set to a dictionary automatically, I presume you must have this code already. For Python 2.3, the __getstate__/__setstate__ methods are *not* required, as long as you use the new pickling protocol (protocol #2) See the 2.3 pickle module docs. Note that the new protocol is also more space-efficient for new-style classes, so you may want to upgrade to using it, anyway. ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-04-21 18:31 Message: Logged In: YES user_id=541557 from that followup of mine, you can clearly see why I use __slots__; sorry for the bad spelling and worse grammar. I *think* I have a solution, but I an not really sure if it is the proper behavior for __slots__. I can not find any documentation, PEP, bug, request, or discussion on how __slots__ should behave in boundry cases such as "__dict__", "__weakref__", etc. Should these be an error if used? Are they assumed? what behavior does having __dict__ as an allowed attribute have? (Does it allow access to the proxy __dict__ and use proper __slots__ conventions and attribute checking? does it circumvent __slots__, i.e. a back door?) __slots__ and inheritance is not clearly specified either. If these things are documented, please flame me with the links. ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-04-18 18:44 Message: Logged In: YES user_id=541557 Well looking deeper at the problem, is seems that __dict__ and __weakref__ are called out as special in Objects/typeobject.c at some point after the 2.2.2 release. looking at teh code, I would expect the followint ot be triggered: if (!may_add_dict || add_dict) { PyErr_SetString(PyExc_TypeError, "__dict__ slot disallowed: " "we already got one"); goto bad_slots; } Ignoring the attrocious goto logic in this section of code, I would have expected to see this triggered. I can understand the IDEA behind always having __slots__ on all classes/types and setting it to contain "__dict__" as teh equivolent of not having slots... But the code does not look like it implements this, and I dont see how this is even working that way yet. Has anyone heard anything about this??? (for now in my code I am having to use __fakedict__ and override all the pickle handling (yuck). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=723540&group_id=5470 From noreply@sourceforge.net Sun May 25 17:44:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 09:44:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support Message-ID: <E19JybL-0000Eu-00@sc8-sf-web4.sourceforge.net> Bugs item #741307, was opened at 2003-05-21 14:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Configure does NOT set properly *FLAGS for thread support Initial Comment: On Tru64Unix 5.1A(but also older version like Digital Unix 4.0 for example), there have to be specified CFLAGS="-pthread" and CXXFLAGS="-pthread", so that configure can detect working pthread.h. In case of Python-2.3b1 even when user set those both variables before running configure, at the link step gets: cc -o python \ Modules/ccpython.o \ libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm ld: Unresolved: __pthread_self __pthread_create __pthread_detach make: *** [python] Error 1 $ This can be easily fixed: $ cc -pthread -o python Modules/ccpython.o libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm $ I guess in this case LDFLAGS are in effect. So, configure should make sure -pthread is appended to all, CFLAGS, CXXFLAGS and LDFLAGS. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 12:44 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 10:20 Message: Logged In: YES user_id=696559 So, this is a solution: CC="cc -pthread" CXX="cxx -pthread" CFLAGS="$CFLAGS -pthread" CXXFLAGS=$CFLAGS ./configure ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 04:28 Message: Logged In: YES user_id=696559 BTW: With gcc, I don't get even to the link step: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o Modules/posixmodule.c: In function `posix_stat': Modules/posixmodule.c:1851: `stat' undeclared (first use in this function) Modules/posixmodule.c:1851: (Each undeclared identifier is reported only once Modules/posixmodule.c:1851: for each function it appears in.) Modules/posixmodule.c: In function `posix_plock': Modules/posixmodule.c:2956: warning: implicit declaration of function `plock' Modules/posixmodule.c: In function `posix_lstat': Modules/posixmodule.c:4683: `lstat' undeclared (first use in this function) Modules/posixmodule.c: In function `posix_unsetenv': Modules/posixmodule.c:5431: warning: implicit declaration of function `unsetenv' make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 03:24 Message: Logged In: YES user_id=696559 This is specific for Dec/Compaq/HP compiler. The manpage for cc says: -pthread Directs the linker to use the threadsafe version of any library speci- fied with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.1c-conformant DECthreads inter- faces in libpthread when linking the program. This option also defines the _REENTRANT macro. As I remeber from experience, it's not enough to use it really as LDFLAG supplied to ld. The code has to be compiled with that flag already and therefore I set CC or CFLAGS to contain this value. Same applies for CXX or CXXFLAGS. Actually, there's a configure macro check, I saw it somewhere in documentation on the web. I posted that once into some my bugreport in GNOME bugzilla. You can dig out from there that URL. Unfortunately, bugzilla searches never worked for me. :( As for gcc: $ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure [...] checking whether pthreads are available without options... no checking whether gcc accepts -Kpthread... no [...] checking for --with-dec-threads... no checking for --with-threads... yes checking for _POSIX_THREADS in unistd.h... yes checking cthreads.h usability... no checking cthreads.h presence... no checking for cthreads.h... no checking mach/cthreads.h usability... no checking mach/cthreads.h presence... no checking for mach/cthreads.h... no checking for --with-pth... no checking for pthread_create in -lpthread... yes checking if PTHREAD_SCOPE_SYSTEM is supported... yes checking for pthread_sigmask... yes from config.log: configure:3753: checking whether pthreads are available without options configure:3779: gcc -o conftest -O2 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c -L/usr/l ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 In file included from configure:3763: /usr/include/pthread.h:312:4: #error "Please compile the module including pthread.h with -pthread" configure:3782: $? = 1 configure: program exited with status 1 configure: failed program was: #line 3761 "configure" #include "confdefs.h" #include <pthread.h> void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } configure:3802: result: no So, to conclude, -pthread has to be specified even for gcc/g++. Simply, always on ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:34 Message: Logged In: YES user_id=33168 Is this only with the Dec/Compaq/HP compiler (cc/cxx)? Do you know if python links ok with gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 From noreply@sourceforge.net Sun May 25 17:44:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 09:44:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-741806 ] test_long failure Message-ID: <E19Jyc0-0004ep-00@sc8-sf-web1.sourceforge.net> Bugs item #741806, was opened at 2003-05-22 11:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test_long failure Initial Comment: $ python Lib/test/test_long.pyc long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow Traceback (most recent call last): File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 442, in ? test_float_overflow() File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 394, in test_float_overflow eval(test, namespace) File "<string>", line 0, in ? ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 $ This happens on Tru64Unix 5.1A, cc/cxx compiled binaries. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 12:44 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 07:40 Message: Logged In: YES user_id=21627 >From http://sourceforge.net/tracker/download.php?group_id=5470&atid=305470&file_id=47386&aid=719359 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-23 04:44 Message: Logged In: YES user_id=696559 Hmm, I see tthe patch in list of patches, but how to download it? :( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:08 Message: Logged In: YES user_id=33168 Patch 719359 should fix this problem. Can you test this patch? ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 11:54 Message: Logged In: YES user_id=696559 ${ac_dA}SIZEOF_LONG${ac_dB}SIZEOF_LONG${ac_dC}8${ac_dD} ${ac_dA}HAVE_LONG_LONG${ac_dB}HAVE_LONG_LONG${ac_dC}1${ac_dD} ${ac_dA}SIZEOF_LONG_LONG${ac_dB}SIZEOF_LONG_LONG${ac_dC}8${ac_dD} ${ac_uA}SIZEOF_LONG${ac_uB}SIZEOF_LONG${ac_uC}8${ac_uD} ${ac_uA}HAVE_LONG_LONG${ac_uB}HAVE_LONG_LONG${ac_uC}1${ac_uD} ${ac_uA}SIZEOF_LONG_LONG${ac_uB}SIZEOF_LONG_LONG${ac_uC}8${ac_uD} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 From noreply@sourceforge.net Sun May 25 17:45:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 09:45:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-738066 ] Interpreter crash: sigfpe on Alpha Message-ID: <E19JycV-0004gS-00@sc8-sf-web1.sourceforge.net> Bugs item #738066, was opened at 2003-05-15 01:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Jørgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter crash: sigfpe on Alpha Initial Comment: Multiplying two numbers makes the interpreter crash. The architecture is an Alpha running: Digital UNIX V4.0F (Rev. 1229); Sat Oct 26 16:44:55 MET DST 2002 Compaq Tru64 UNIX V4.0F (Rev. 1229); Thu Mar 23 08:45:31 MET 2000 Python 2.2.1 (#1, Jun 4 2002, 15:33:18) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.uname() ('OSF1', 'asrv', 'V4.0', '1229', 'alpha') >>> 1e300 * 1e300 Floating exception (core dumped) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 12:45 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-19 13:42 Message: Logged In: YES user_id=31435 If someone knows how to make a config patch to pass -ieee automatically to this compiler, that would be helpful -- IIRC, this comes up a couple times per year. ---------------------------------------------------------------------- Comment By: Jens Jørgen Mortensen (jensj) Date: 2003-05-19 11:52 Message: Logged In: YES user_id=716463 I tried with Python-2.3b1: Same problem. I then tried building with -ieee added to CFLAGS in Makefile - That solved the problem! Thanks ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-15 14:31 Message: Logged In: YES user_id=31435 Python inherits its floating-point behavior from whatever your C compiler and libraries happen to do. So, presumably a plain C program would do the same thing with this example. If that's not what you want, your C compiler probably supports some option to compile code that acts more the way you want it to work, and then you should compile Python with that option too. IIRC (I've never run on an Alpha), by default Alphas don't have compliant IEEE-754 fp arithmetic, and by default C compilers on Alphas don't try to repair that. If the compiler you're using as an option named "-ieee", try it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-15 10:11 Message: Logged In: YES user_id=33168 Is this still a problem with 2.2.2 or 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 From noreply@sourceforge.net Sun May 25 17:46:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 09:46:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-693094 ] Python does not build --with-pydebug on Tru64 with vendor cc Message-ID: <E19JydE-0000J2-00@sc8-sf-web4.sourceforge.net> Bugs item #693094, was opened at 2003-02-25 13:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephan A. Terre (sfiedler) Assigned to: Neal Norwitz (nnorwitz) Summary: Python does not build --with-pydebug on Tru64 with vendor cc Initial Comment: The default standards-compliance level for the Compaq/HP compiler defines the assert macro using the if statement (if...then) rather than the ternary if expression (?:). As a result, when Python is configured --with-pydebug (so NDEBUG is not defined), the macro Py_SAFE_DOWNCAST expands to illegal C (containing a statement inside an expression). This can be fixed by asserting the -std switch to the vendor compiler. Testing of 2.2.2 CVS and 2.3 CVS indicates that there is no bad side effect to asserting -std. I hope to develop a fix for this in configure.in sometime in the next couple of days. When I have done so, I will attach it to this bug. For the record, here are the variations of the -std switch on the vendor compiler: -std0 Selects the K & R language mode. This is the default. Enforces the K & R programming style, with certain ANSI extensions in areas where the K & R behavior is undefined or ambiguous. In general, -std0 compiles most pre-ANSI C programs and produces expected results. The -std0 option causes the __STDC__ macro to be undefined. -std Selects the relaxed ANSI language mode. Enforces the ANSI C standard, but allows some common programming practices disallowed by the stan- dard. This option does not restrict the Tru64 UNIX name space (for example, the names defined in system header files). To restrict that name space so that only ANSI C reserved names are visible from the ANSI C header files, use the _ANSI_C_SOURCE macro. See standards(5) for more details. This option causes the macro __STDC_ to be defined to 0. -std1 Selects the strict ANSI language mode. Strictly enforces the ANSI C standard and all its prohibitions (such as those that apply to the han- dling of void types, the definition of lvalues in expressions, the mix- ing of integrals and pointers, and the modification of rvalues). This option does not restrict the Tru64 UNIX name space (for example, the names defined in system header files). To restrict that name space so that only ANSI C reserved names are visible from the ANSI C header files, use the _ANSI_C_SOURCE macro. See standards(5) for more details. This option causes the macro __STDC_ to be defined to 1. Note that this option also affects linker-defined symbols. See ld(1) for more infor- mation. This option turns on ANSI aliasing rules (-ansi_alias option). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 12:46 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Stephan A. Terre (sfiedler) Date: 2003-02-27 19:58 Message: Logged In: YES user_id=246063 Attached to this bug is a patch to configure.in and configure. I believe pretty much all of the three decisions I made need review :) 1. I put the -std flag in BASECFLAGS an OSF1-specific case in the non-gcc branch. Should there be some other check here that we're using the vendor C compiler? If so, can anyone point me at an example? 2. Upon testing, I found that the getpgrp function has a different signature when compiled with -std than without. As a result, the posixmodule didn't build. My solution was to change the definition of CC in configure.in to be "$CC $BASECFLAGS $OPT" after the last change to OPT and BASECFLAGS. My thinking is that we ought to be running feature and behavior tests with the flags that we'll be using to build the interpreter. However, if this goes against the spirit or policy of autoconf, we should do something else! 3. I happened to notice an XXX about Monterey, so I did a little investigation and added to the note. Hopefully this is not a gaffe. I have tested the changes to configure.in on Tru64 4.0F both with and without the --with-pydebug flag to configure. The test suite behaved the same in each case as before my mods. I also tested the changes --with-pydebug on a Red Hat 7 system; they seemed good there too. If I should have put this patch in the Patch Manager rather than attaching to the bug directly, I apologize and promise never to do it wrongly again :) Please let me know by posting a followup here or via email if there is anything else I should do for this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470 From noreply@sourceforge.net Sun May 25 19:00:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 11:00:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-743267 ] super passes bad arguments to __get__ when used w/class Message-ID: <E19Jzna-0007e3-00@sc8-sf-web1.sourceforge.net> Bugs item #743267, was opened at 2003-05-25 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=743267&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: super passes bad arguments to __get__ when used w/class Initial Comment: Run the following code to demonstrate the issue: ==== class Getter(object): def __get__(self, ob, typ=None): print "called with", (ob, typ) class Base(object): foo = Getter() class Subclass(Base): pass print print Base().foo Subclass().foo super(Subclass,Subclass()).foo Base.foo Subclass.foo super(Subclass,Subclass).foo ==== Notice that super(Subclass,Subclass).foo is calling the descriptor with the *class* object, not 'None' as is done for the analagous cases that don't use super(). The only reason this ever "works" is because 'classmethod' ignores the 'ob' parameter to '__get__'. However, this breaks when using 'super' to access property descriptors in 2.3, and it will also break any user-defined descriptors that are accessed via super(). The behavior is the same in 2.2, and is arguably broken there as well. For example, 'super(someclass,someclass).X' (where 'X' is a normal instance method) results in X being a *bound* method, bound to the class, rather than an *unbound* method, ready for use with an explicit instance. Personally, I would be happy if super() grew an extra argument to disambiguate whether you are doing a (class,instance) or (class,class) call, anyway. When using super() with metaclasses, I've encountered situations where super() guessed wrong, because I was using a type that was both an instance of, and a subclass of, the same type. Being able to explicitly request that this "class method" form of super is being used, would eliminate this confusion as well. In the face of ambiguity... ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470 From noreply@sourceforge.net Sun May 25 21:37:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 13:37:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-743324 ] configure.in reference to /bin/true Message-ID: <E19K2FY-0004jo-00@sc8-sf-web1.sourceforge.net> Bugs item #743324, was opened at 2003-05-25 22: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=743324&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: configure.in reference to /bin/true Initial Comment: Since rev. 1.405 configure.in has a reference to /bin/true, which doesn't exist on MacOSX (true is in /usr/bin/true). I think replacing with plain "true" is good enough, but I'm not sure, I assume the /bin/ true construct may be there for a good reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743324&group_id=5470 From noreply@sourceforge.net Sun May 25 21:44:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 13:44:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-743324 ] configure.in reference to /bin/true Message-ID: <E19K2MM-0001Lo-00@sc8-sf-web3.sourceforge.net> Bugs item #743324, was opened at 2003-05-25 22:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743324&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: configure.in reference to /bin/true Initial Comment: Since rev. 1.405 configure.in has a reference to /bin/true, which doesn't exist on MacOSX (true is in /usr/bin/true). I think replacing with plain "true" is good enough, but I'm not sure, I assume the /bin/ true construct may be there for a good reason. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-05-25 22:44 Message: Logged In: YES user_id=21627 Can you try 742741 instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743324&group_id=5470 From noreply@sourceforge.net Mon May 26 05:14:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 25 May 2003 21:14:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-724621 ] email/quopriMIME.py exception on int (lstrip) Message-ID: <E19K9Nl-0008Je-00@sc8-sf-web2.sourceforge.net> Bugs item #724621, was opened at 2003-04-20 10:36 Message generated for change (Comment added) made by myudkowsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Open Resolution: None Priority: 5 Submitted By: Moshe Yudkowsky (myudkowsky) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/quopriMIME.py exception on int (lstrip) Initial Comment: Python 2.3a2+, Debian Summary: when I use the as_string() method on a multipart, multilevel message, I get an exception from email/quopriMIME.py, line 84, complaining about lstrip() of an integer. Initial condtions: I have a script that reads an email message, extracts some information, encapsulates the message and then forwards it with some commentary. This script works under Python 2.2.2. Failure: This script does not run under 2.3a2+ -- it fails on the as_string() method. In particular, at the file/lineno given above. Using the debugger, I see that in fact there *is* an integer at that point, the digit "1" to be exact. Looking up in the stack, I see that this function was called by the method _encode_chunks in Headers.py, and that the "newchunks" was [ (1, us-ascii ) ]. Please let me know if you need copies of the scripts, email messages, etc. ---------------------------------------------------------------------- >Comment By: Moshe Yudkowsky (myudkowsky) Date: 2003-05-25 23:14 Message: Logged In: YES user_id=288768 Now, of course, I'm having trouble generating the exact same error. The enclosed script WFM under 2.2.2, but fails under 2.3b1+. The fault still seems to lie with "newchunks" but now the failure comes from Charset.py: Traceback (most recent call last): File "mailfail.py", line 203, in ? outMailString = wrapper.as_string() File "/usr/lib/python2.3/email/Message.py", line 113, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 130, in _write self._dispatch(msg) File "/usr/lib/python2.3/email/Generator.py", line 156, in _dispatch meth(msg) File "/usr/lib/python2.3/email/Generator.py", line 230, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 130, in _write self._dispatch(msg) File "/usr/lib/python2.3/email/Generator.py", line 156, in _dispatch meth(msg) File "/usr/lib/python2.3/email/Generator.py", line 297, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 137, in _write self._write_headers(msg) File "/usr/lib/python2.3/email/Generator.py", line 183, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/lib/python2.3/email/Header.py", line 412, in encode newchunks += self._split(s, charset, targetlen, splitchars) File "/usr/lib/python2.3/email/Header.py", line 297, in _split elen = charset.encoded_header_len(encoded) File "/usr/lib/python2.3/email/Charset.py", line 341, in encoded_header_len return len(s) I can either continue to try and recreate the original error, or if this is sufficient information to debug I'll stop now. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 15:00 Message: Logged In: YES user_id=12800 Moving to Pending, waiting on more information. In 14 days, if there's no follow up this bug report will be automatically closed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-15 09:08 Message: Logged In: YES user_id=12800 Yes, please upload (not paste) all relevant files needed for me to reproduce the problem. Please boil down your example as much as possible, but be sure to include a complete example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 From noreply@sourceforge.net Mon May 26 08:15:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 00:15:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-738066 ] Interpreter crash: sigfpe on Alpha Message-ID: <E19KCCh-00089d-00@sc8-sf-web1.sourceforge.net> Bugs item #738066, was opened at 2003-05-15 07:52 Message generated for change (Comment added) made by jensj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Jørgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter crash: sigfpe on Alpha Initial Comment: Multiplying two numbers makes the interpreter crash. The architecture is an Alpha running: Digital UNIX V4.0F (Rev. 1229); Sat Oct 26 16:44:55 MET DST 2002 Compaq Tru64 UNIX V4.0F (Rev. 1229); Thu Mar 23 08:45:31 MET 2000 Python 2.2.1 (#1, Jun 4 2002, 15:33:18) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.uname() ('OSF1', 'asrv', 'V4.0', '1229', 'alpha') >>> 1e300 * 1e300 Floating exception (core dumped) ---------------------------------------------------------------------- >Comment By: Jens Jørgen Mortensen (jensj) Date: 2003-05-26 09:15 Message: Logged In: YES user_id=716463 I have tested the patch (http://python.org/sf/719359) and it fixes my bug. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 18:45 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-19 19:42 Message: Logged In: YES user_id=31435 If someone knows how to make a config patch to pass -ieee automatically to this compiler, that would be helpful -- IIRC, this comes up a couple times per year. ---------------------------------------------------------------------- Comment By: Jens Jørgen Mortensen (jensj) Date: 2003-05-19 17:52 Message: Logged In: YES user_id=716463 I tried with Python-2.3b1: Same problem. I then tried building with -ieee added to CFLAGS in Makefile - That solved the problem! Thanks ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-15 20:31 Message: Logged In: YES user_id=31435 Python inherits its floating-point behavior from whatever your C compiler and libraries happen to do. So, presumably a plain C program would do the same thing with this example. If that's not what you want, your C compiler probably supports some option to compile code that acts more the way you want it to work, and then you should compile Python with that option too. IIRC (I've never run on an Alpha), by default Alphas don't have compliant IEEE-754 fp arithmetic, and by default C compilers on Alphas don't try to repair that. If the compiler you're using as an option named "-ieee", try it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-15 16:11 Message: Logged In: YES user_id=33168 Is this still a problem with 2.2.2 or 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 From noreply@sourceforge.net Mon May 26 10:09:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 02:09:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-743324 ] configure.in reference to /bin/true Message-ID: <E19KDys-0002hE-00@sc8-sf-web4.sourceforge.net> Bugs item #743324, was opened at 2003-05-25 22:37 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743324&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: configure.in reference to /bin/true Initial Comment: Since rev. 1.405 configure.in has a reference to /bin/true, which doesn't exist on MacOSX (true is in /usr/bin/true). I think replacing with plain "true" is good enough, but I'm not sure, I assume the /bin/ true construct may be there for a good reason. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-26 11:09 Message: Logged In: YES user_id=45365 Yes, that fixed it. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-25 22:44 Message: Logged In: YES user_id=21627 Can you try 742741 instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743324&group_id=5470 From noreply@sourceforge.net Mon May 26 15:02:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 07:02:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-741307 ] Configure does NOT set properly *FLAGS for thread support Message-ID: <E19KIYP-000654-00@sc8-sf-web3.sourceforge.net> Bugs item #741307, was opened at 2003-05-21 14:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: Configure does NOT set properly *FLAGS for thread support Initial Comment: On Tru64Unix 5.1A(but also older version like Digital Unix 4.0 for example), there have to be specified CFLAGS="-pthread" and CXXFLAGS="-pthread", so that configure can detect working pthread.h. In case of Python-2.3b1 even when user set those both variables before running configure, at the link step gets: cc -o python \ Modules/ccpython.o \ libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm ld: Unresolved: __pthread_self __pthread_create __pthread_detach make: *** [python] Error 1 $ This can be easily fixed: $ cc -pthread -o python Modules/ccpython.o libpython2.3.a -lrt -L/usr/local/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib -lm $ I guess in this case LDFLAGS are in effect. So, configure should make sure -pthread is appended to all, CFLAGS, CXXFLAGS and LDFLAGS. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 10:02 Message: Logged In: YES user_id=33168 A solution was already checked in that solves thread problems for several architectures. Please test current CVS and report if it works or not. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 12:44 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 10:20 Message: Logged In: YES user_id=696559 So, this is a solution: CC="cc -pthread" CXX="cxx -pthread" CFLAGS="$CFLAGS -pthread" CXXFLAGS=$CFLAGS ./configure ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 04:28 Message: Logged In: YES user_id=696559 BTW: With gcc, I don't get even to the link step: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o Modules/posixmodule.c: In function `posix_stat': Modules/posixmodule.c:1851: `stat' undeclared (first use in this function) Modules/posixmodule.c:1851: (Each undeclared identifier is reported only once Modules/posixmodule.c:1851: for each function it appears in.) Modules/posixmodule.c: In function `posix_plock': Modules/posixmodule.c:2956: warning: implicit declaration of function `plock' Modules/posixmodule.c: In function `posix_lstat': Modules/posixmodule.c:4683: `lstat' undeclared (first use in this function) Modules/posixmodule.c: In function `posix_unsetenv': Modules/posixmodule.c:5431: warning: implicit declaration of function `unsetenv' make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 03:24 Message: Logged In: YES user_id=696559 This is specific for Dec/Compaq/HP compiler. The manpage for cc says: -pthread Directs the linker to use the threadsafe version of any library speci- fied with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.1c-conformant DECthreads inter- faces in libpthread when linking the program. This option also defines the _REENTRANT macro. As I remeber from experience, it's not enough to use it really as LDFLAG supplied to ld. The code has to be compiled with that flag already and therefore I set CC or CFLAGS to contain this value. Same applies for CXX or CXXFLAGS. Actually, there's a configure macro check, I saw it somewhere in documentation on the web. I posted that once into some my bugreport in GNOME bugzilla. You can dig out from there that URL. Unfortunately, bugzilla searches never worked for me. :( As for gcc: $ CFLAGS="-O2" CXXFLAGS="-O2" CC=gcc CXX=g++ ./configure [...] checking whether pthreads are available without options... no checking whether gcc accepts -Kpthread... no [...] checking for --with-dec-threads... no checking for --with-threads... yes checking for _POSIX_THREADS in unistd.h... yes checking cthreads.h usability... no checking cthreads.h presence... no checking for cthreads.h... no checking mach/cthreads.h usability... no checking mach/cthreads.h presence... no checking for mach/cthreads.h... no checking for --with-pth... no checking for pthread_create in -lpthread... yes checking if PTHREAD_SCOPE_SYSTEM is supported... yes checking for pthread_sigmask... yes from config.log: configure:3753: checking whether pthreads are available without options configure:3779: gcc -o conftest -O2 -I/software/@sys/usr/include -I/usr/local/include -I/usr/local/openssl/include conftest.c -L/usr/l ocal/lib -L/software/@sys/usr/lib -L/usr/local/openssl/lib -L/usr/lib >&5 In file included from configure:3763: /usr/include/pthread.h:312:4: #error "Please compile the module including pthread.h with -pthread" configure:3782: $? = 1 configure: program exited with status 1 configure: failed program was: #line 3761 "configure" #include "confdefs.h" #include <pthread.h> void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } configure:3802: result: no So, to conclude, -pthread has to be specified even for gcc/g++. Simply, always on ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:34 Message: Logged In: YES user_id=33168 Is this only with the Dec/Compaq/HP compiler (cc/cxx)? Do you know if python links ok with gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741307&group_id=5470 From noreply@sourceforge.net Mon May 26 15:14:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 07:14:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-741806 ] test_long failure Message-ID: <E19KIjk-0000MY-00@sc8-sf-web2.sourceforge.net> Bugs item #741806, was opened at 2003-05-22 11:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_long failure Initial Comment: $ python Lib/test/test_long.pyc long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow Traceback (most recent call last): File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 442, in ? test_float_overflow() File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 394, in test_float_overflow eval(test, namespace) File "<string>", line 0, in ? ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 $ This happens on Tru64Unix 5.1A, cc/cxx compiled binaries. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 10:14 Message: Logged In: YES user_id=33168 Checked in as: * configure 1.402 * configure.in 1.413 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 12:44 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-24 07:40 Message: Logged In: YES user_id=21627 >From http://sourceforge.net/tracker/download.php?group_id=5470&atid=305470&file_id=47386&aid=719359 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-23 04:44 Message: Logged In: YES user_id=696559 Hmm, I see tthe patch in list of patches, but how to download it? :( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:08 Message: Logged In: YES user_id=33168 Patch 719359 should fix this problem. Can you test this patch? ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 11:54 Message: Logged In: YES user_id=696559 ${ac_dA}SIZEOF_LONG${ac_dB}SIZEOF_LONG${ac_dC}8${ac_dD} ${ac_dA}HAVE_LONG_LONG${ac_dB}HAVE_LONG_LONG${ac_dC}1${ac_dD} ${ac_dA}SIZEOF_LONG_LONG${ac_dB}SIZEOF_LONG_LONG${ac_dC}8${ac_dD} ${ac_uA}SIZEOF_LONG${ac_uB}SIZEOF_LONG${ac_uC}8${ac_uD} ${ac_uA}HAVE_LONG_LONG${ac_uB}HAVE_LONG_LONG${ac_uC}1${ac_uD} ${ac_uA}SIZEOF_LONG_LONG${ac_uB}SIZEOF_LONG_LONG${ac_uC}8${ac_uD} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 From noreply@sourceforge.net Mon May 26 15:14:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 07:14:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-738066 ] Interpreter crash: sigfpe on Alpha Message-ID: <E19KIkA-0001ai-00@sc8-sf-web1.sourceforge.net> Bugs item #738066, was opened at 2003-05-15 01:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jens Jørgen Mortensen (jensj) >Assigned to: Neal Norwitz (nnorwitz) Summary: Interpreter crash: sigfpe on Alpha Initial Comment: Multiplying two numbers makes the interpreter crash. The architecture is an Alpha running: Digital UNIX V4.0F (Rev. 1229); Sat Oct 26 16:44:55 MET DST 2002 Compaq Tru64 UNIX V4.0F (Rev. 1229); Thu Mar 23 08:45:31 MET 2000 Python 2.2.1 (#1, Jun 4 2002, 15:33:18) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.uname() ('OSF1', 'asrv', 'V4.0', '1229', 'alpha') >>> 1e300 * 1e300 Floating exception (core dumped) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 10:14 Message: Logged In: YES user_id=33168 Checked in as: * configure 1.402 * configure.in 1.413 ---------------------------------------------------------------------- Comment By: Jens Jørgen Mortensen (jensj) Date: 2003-05-26 03:15 Message: Logged In: YES user_id=716463 I have tested the patch (http://python.org/sf/719359) and it fixes my bug. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 12:45 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-19 13:42 Message: Logged In: YES user_id=31435 If someone knows how to make a config patch to pass -ieee automatically to this compiler, that would be helpful -- IIRC, this comes up a couple times per year. ---------------------------------------------------------------------- Comment By: Jens Jørgen Mortensen (jensj) Date: 2003-05-19 11:52 Message: Logged In: YES user_id=716463 I tried with Python-2.3b1: Same problem. I then tried building with -ieee added to CFLAGS in Makefile - That solved the problem! Thanks ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-15 14:31 Message: Logged In: YES user_id=31435 Python inherits its floating-point behavior from whatever your C compiler and libraries happen to do. So, presumably a plain C program would do the same thing with this example. If that's not what you want, your C compiler probably supports some option to compile code that acts more the way you want it to work, and then you should compile Python with that option too. IIRC (I've never run on an Alpha), by default Alphas don't have compliant IEEE-754 fp arithmetic, and by default C compilers on Alphas don't try to repair that. If the compiler you're using as an option named "-ieee", try it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-15 10:11 Message: Logged In: YES user_id=33168 Is this still a problem with 2.2.2 or 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738066&group_id=5470 From noreply@sourceforge.net Mon May 26 15:16:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 07:16:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-693094 ] Python does not build --with-pydebug on Tru64 with vendor cc Message-ID: <E19KIlg-0000Vv-00@sc8-sf-web2.sourceforge.net> Bugs item #693094, was opened at 2003-02-25 13:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stephan A. Terre (sfiedler) Assigned to: Neal Norwitz (nnorwitz) Summary: Python does not build --with-pydebug on Tru64 with vendor cc Initial Comment: The default standards-compliance level for the Compaq/HP compiler defines the assert macro using the if statement (if...then) rather than the ternary if expression (?:). As a result, when Python is configured --with-pydebug (so NDEBUG is not defined), the macro Py_SAFE_DOWNCAST expands to illegal C (containing a statement inside an expression). This can be fixed by asserting the -std switch to the vendor compiler. Testing of 2.2.2 CVS and 2.3 CVS indicates that there is no bad side effect to asserting -std. I hope to develop a fix for this in configure.in sometime in the next couple of days. When I have done so, I will attach it to this bug. For the record, here are the variations of the -std switch on the vendor compiler: -std0 Selects the K & R language mode. This is the default. Enforces the K & R programming style, with certain ANSI extensions in areas where the K & R behavior is undefined or ambiguous. In general, -std0 compiles most pre-ANSI C programs and produces expected results. The -std0 option causes the __STDC__ macro to be undefined. -std Selects the relaxed ANSI language mode. Enforces the ANSI C standard, but allows some common programming practices disallowed by the stan- dard. This option does not restrict the Tru64 UNIX name space (for example, the names defined in system header files). To restrict that name space so that only ANSI C reserved names are visible from the ANSI C header files, use the _ANSI_C_SOURCE macro. See standards(5) for more details. This option causes the macro __STDC_ to be defined to 0. -std1 Selects the strict ANSI language mode. Strictly enforces the ANSI C standard and all its prohibitions (such as those that apply to the han- dling of void types, the definition of lvalues in expressions, the mix- ing of integrals and pointers, and the modification of rvalues). This option does not restrict the Tru64 UNIX name space (for example, the names defined in system header files). To restrict that name space so that only ANSI C reserved names are visible from the ANSI C header files, use the _ANSI_C_SOURCE macro. See standards(5) for more details. This option causes the macro __STDC_ to be defined to 1. Note that this option also affects linker-defined symbols. See ld(1) for more infor- mation. This option turns on ANSI aliasing rules (-ansi_alias option). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 10:16 Message: Logged In: YES user_id=33168 Checked in as: * configure 1.402 * configure.in 1.413 Please test the current CVS. It was a little different from the patch here. I think it should work though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 12:46 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Stephan A. Terre (sfiedler) Date: 2003-02-27 19:58 Message: Logged In: YES user_id=246063 Attached to this bug is a patch to configure.in and configure. I believe pretty much all of the three decisions I made need review :) 1. I put the -std flag in BASECFLAGS an OSF1-specific case in the non-gcc branch. Should there be some other check here that we're using the vendor C compiler? If so, can anyone point me at an example? 2. Upon testing, I found that the getpgrp function has a different signature when compiled with -std than without. As a result, the posixmodule didn't build. My solution was to change the definition of CC in configure.in to be "$CC $BASECFLAGS $OPT" after the last change to OPT and BASECFLAGS. My thinking is that we ought to be running feature and behavior tests with the flags that we'll be using to build the interpreter. However, if this goes against the spirit or policy of autoconf, we should do something else! 3. I happened to notice an XXX about Monterey, so I did a little investigation and added to the note. Hopefully this is not a gaffe. I have tested the changes to configure.in on Tru64 4.0F both with and without the --with-pydebug flag to configure. The test suite behaved the same in each case as before my mods. I also tested the changes --with-pydebug on a Red Hat 7 system; they seemed good there too. If I should have put this patch in the Patch Manager rather than attaching to the bug directly, I apologize and promise never to do it wrongly again :) Please let me know by posting a followup here or via email if there is anything else I should do for this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470 From noreply@sourceforge.net Mon May 26 15:30:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 07:30:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-743692 ] test_socketserver: Fatal error: Invalid thread state Message-ID: <E19KIzz-0007Wn-00@sc8-sf-web3.sourceforge.net> Bugs item #743692, was opened at 2003-05-26 10:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Mark Hammond (mhammond) Summary: test_socketserver: Fatal error: Invalid thread state Initial Comment: Mark, I believe this started happening on Solaris 8 (only AFAIK) after some of your thread changes. Do you have access to a Solaris 8 box? I can try to debug if you give me some ideas. This is happening on the snake farm. Actually, we have a Sol8 box here. I can try to fire it up and see if the problem exists on that box. If so, I can give you access. When running test_socketserver, some way through the test there's the fatal error. Fatal Python error: Invalid thread state for this thread Let me know what more info I can provide. Sorry, short on ideas/time, just wanted to get this documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 From noreply@sourceforge.net Mon May 26 15:26:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 07:26:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-724621 ] email/quopriMIME.py exception on int (lstrip) Message-ID: <E19KIwE-0006to-00@sc8-sf-web4.sourceforge.net> Bugs item #724621, was opened at 2003-04-20 10:36 Message generated for change (Comment added) made by myudkowsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Moshe Yudkowsky (myudkowsky) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/quopriMIME.py exception on int (lstrip) Initial Comment: Python 2.3a2+, Debian Summary: when I use the as_string() method on a multipart, multilevel message, I get an exception from email/quopriMIME.py, line 84, complaining about lstrip() of an integer. Initial condtions: I have a script that reads an email message, extracts some information, encapsulates the message and then forwards it with some commentary. This script works under Python 2.2.2. Failure: This script does not run under 2.3a2+ -- it fails on the as_string() method. In particular, at the file/lineno given above. Using the debugger, I see that in fact there *is* an integer at that point, the digit "1" to be exact. Looking up in the stack, I see that this function was called by the method _encode_chunks in Headers.py, and that the "newchunks" was [ (1, us-ascii ) ]. Please let me know if you need copies of the scripts, email messages, etc. ---------------------------------------------------------------------- >Comment By: Moshe Yudkowsky (myudkowsky) Date: 2003-05-26 09:26 Message: Logged In: YES user_id=288768 I have deleted the original file, in which I'd accidentally left my email address, and replaced it with an anonymized version. ---------------------------------------------------------------------- Comment By: Moshe Yudkowsky (myudkowsky) Date: 2003-05-25 23:14 Message: Logged In: YES user_id=288768 Now, of course, I'm having trouble generating the exact same error. The enclosed script WFM under 2.2.2, but fails under 2.3b1+. The fault still seems to lie with "newchunks" but now the failure comes from Charset.py: Traceback (most recent call last): File "mailfail.py", line 203, in ? outMailString = wrapper.as_string() File "/usr/lib/python2.3/email/Message.py", line 113, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 130, in _write self._dispatch(msg) File "/usr/lib/python2.3/email/Generator.py", line 156, in _dispatch meth(msg) File "/usr/lib/python2.3/email/Generator.py", line 230, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 130, in _write self._dispatch(msg) File "/usr/lib/python2.3/email/Generator.py", line 156, in _dispatch meth(msg) File "/usr/lib/python2.3/email/Generator.py", line 297, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 137, in _write self._write_headers(msg) File "/usr/lib/python2.3/email/Generator.py", line 183, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/lib/python2.3/email/Header.py", line 412, in encode newchunks += self._split(s, charset, targetlen, splitchars) File "/usr/lib/python2.3/email/Header.py", line 297, in _split elen = charset.encoded_header_len(encoded) File "/usr/lib/python2.3/email/Charset.py", line 341, in encoded_header_len return len(s) I can either continue to try and recreate the original error, or if this is sufficient information to debug I'll stop now. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 15:00 Message: Logged In: YES user_id=12800 Moving to Pending, waiting on more information. In 14 days, if there's no follow up this bug report will be automatically closed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-15 09:08 Message: Logged In: YES user_id=12800 Yes, please upload (not paste) all relevant files needed for me to reproduce the problem. Please boil down your example as much as possible, but be sure to include a complete example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 From noreply@sourceforge.net Mon May 26 17:56:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 09:56:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-665194 ] datetime-RFC2822 roundtripping Message-ID: <E19KLGU-0007r0-00@sc8-sf-web2.sourceforge.net> Bugs item #665194, was opened at 2003-01-09 19:24 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-05-26 18:56 Message: Logged In: YES user_id=89016 time.strptime() is locale aware, but RFC1123 & RFC822 require english day and month names, so time.strptime() can't be used as-is. (And of course time.strptime() only works for formatting, not for parsing) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-24 00:46 Message: Logged In: YES user_id=357491 time.strptime doesn't solve your problem? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 14:05 Message: Logged In: YES user_id=89016 totimestamp() should be the inverse of fromtimestamp(), i.e. foo.totimestamp() should be the same as time.mktime(foo.timetuple()). datetime.datetime.totimestamp() should raise OverflowError iff time.mktime() raises OverflowError. But as this may lose precision, I'd say it would be better, if datetime supported RFC1123 conversion directly, i.e. two methods frommime() and tomime(), that parse and format strings like "Sun, 06 Nov 1994 08:49:37 GMT" (what rfc822.parsedate() and rfc822.formatdate() do) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 17:32 Message: Logged In: YES user_id=31435 Define what totimestamp() should do. The range of timestamps supported by the *platform* C library (and so indirectly by Python's time module) isn't defined by any standard, and isn't easily discoverable either. It may or may not work before 1970, may or may not after 2038. datetime covers days far outside that range. Note that even a double doesn't have enough bits of precision to cover the full range of datetime values, either. In contrast, ordinals are wholly under Python's control, so we can promise surprise-free conversion in both directions. All we can promise about timestamps is that if the platform supports a timestamp for a time in datetime's range, datetime can make sense of it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-11 13:33 Message: Logged In: YES user_id=89016 OK, I'll mark this a feature request. datetime has fromordinal() and toordinal(), it has fromtimestamp(), so I'd say a totimestamp() method would be a logical addition. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 06:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 From noreply@sourceforge.net Mon May 26 19:11:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 11:11:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-693094 ] Python does not build --with-pydebug on Tru64 with vendor cc Message-ID: <E19KMRj-0004GM-00@sc8-sf-web1.sourceforge.net> Bugs item #693094, was opened at 2003-02-25 11:48 Message generated for change (Comment added) made by sfiedler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470 Category: Build Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Stephan A. Terre (sfiedler) Assigned to: Neal Norwitz (nnorwitz) Summary: Python does not build --with-pydebug on Tru64 with vendor cc Initial Comment: The default standards-compliance level for the Compaq/HP compiler defines the assert macro using the if statement (if...then) rather than the ternary if expression (?:). As a result, when Python is configured --with-pydebug (so NDEBUG is not defined), the macro Py_SAFE_DOWNCAST expands to illegal C (containing a statement inside an expression). This can be fixed by asserting the -std switch to the vendor compiler. Testing of 2.2.2 CVS and 2.3 CVS indicates that there is no bad side effect to asserting -std. I hope to develop a fix for this in configure.in sometime in the next couple of days. When I have done so, I will attach it to this bug. For the record, here are the variations of the -std switch on the vendor compiler: -std0 Selects the K & R language mode. This is the default. Enforces the K & R programming style, with certain ANSI extensions in areas where the K & R behavior is undefined or ambiguous. In general, -std0 compiles most pre-ANSI C programs and produces expected results. The -std0 option causes the __STDC__ macro to be undefined. -std Selects the relaxed ANSI language mode. Enforces the ANSI C standard, but allows some common programming practices disallowed by the stan- dard. This option does not restrict the Tru64 UNIX name space (for example, the names defined in system header files). To restrict that name space so that only ANSI C reserved names are visible from the ANSI C header files, use the _ANSI_C_SOURCE macro. See standards(5) for more details. This option causes the macro __STDC_ to be defined to 0. -std1 Selects the strict ANSI language mode. Strictly enforces the ANSI C standard and all its prohibitions (such as those that apply to the han- dling of void types, the definition of lvalues in expressions, the mix- ing of integrals and pointers, and the modification of rvalues). This option does not restrict the Tru64 UNIX name space (for example, the names defined in system header files). To restrict that name space so that only ANSI C reserved names are visible from the ANSI C header files, use the _ANSI_C_SOURCE macro. See standards(5) for more details. This option causes the macro __STDC_ to be defined to 1. Note that this option also affects linker-defined symbols. See ld(1) for more infor- mation. This option turns on ANSI aliasing rules (-ansi_alias option). ---------------------------------------------------------------------- >Comment By: Stephan A. Terre (sfiedler) Date: 2003-05-26 11:11 Message: Logged In: YES user_id=246063 I'll try the fix tomorrow when I am at work and have access to a Tru64 machine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 07:16 Message: Logged In: YES user_id=33168 Checked in as: * configure 1.402 * configure.in 1.413 Please test the current CVS. It was a little different from the patch here. I think it should work though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 09:46 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Stephan A. Terre (sfiedler) Date: 2003-02-27 17:58 Message: Logged In: YES user_id=246063 Attached to this bug is a patch to configure.in and configure. I believe pretty much all of the three decisions I made need review :) 1. I put the -std flag in BASECFLAGS an OSF1-specific case in the non-gcc branch. Should there be some other check here that we're using the vendor C compiler? If so, can anyone point me at an example? 2. Upon testing, I found that the getpgrp function has a different signature when compiled with -std than without. As a result, the posixmodule didn't build. My solution was to change the definition of CC in configure.in to be "$CC $BASECFLAGS $OPT" after the last change to OPT and BASECFLAGS. My thinking is that we ought to be running feature and behavior tests with the flags that we'll be using to build the interpreter. However, if this goes against the spirit or policy of autoconf, we should do something else! 3. I happened to notice an XXX about Monterey, so I did a little investigation and added to the note. Hopefully this is not a gaffe. I have tested the changes to configure.in on Tru64 4.0F both with and without the --with-pydebug flag to configure. The test suite behaved the same in each case as before my mods. I also tested the changes --with-pydebug on a Red Hat 7 system; they seemed good there too. If I should have put this patch in the Patch Manager rather than attaching to the bug directly, I apologize and promise never to do it wrongly again :) Please let me know by posting a followup here or via email if there is anything else I should do for this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470 From noreply@sourceforge.net Tue May 27 01:10:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 17:10:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-643571 ] Pythonwin : close() on a stdout Message-ID: <E19KS3H-0001BV-00@sc8-sf-web1.sourceforge.net> Bugs item #643571, was opened at 2002-11-25 09:28 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643571&group_id=5470 >Category: IDLE Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Xavier BASSERY (balthus) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin : close() on a stdout Initial Comment: I need to treat file objects and sys.stdout object as one. So I can write a class that writes likewise in a file or to standard output. The problem came when I called the close() method of an sys.stdout object. I've seen that in Pythonwin, sys.stdout has such a method. This is not the case in the standard python. And calling it causes that : File "C:\Python22\lib\site-packages\Pythonwin\pywin\scintilla\document.py", line 153, in __call__ return apply(getattr(v, self.name), (std, extra)) AttributeError: OnBraceMatch win32ui: Exception in OnNotify() handler I know that the right way to go is to avoid using the close() method. But methinks it's a bug that the method is available in the IDE of pythonwin. ---------------------------------------------------------------------- Comment By: Xavier BASSERY (balthus) Date: 2002-11-25 09:38 Message: Logged In: YES user_id=653276 >> sys.stdout has such a method. >> This is not the case in the standard python I was not completely right here, in console mode there is the close() methode for sys.stdout object. It's not the case in the IDLE ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643571&group_id=5470 From noreply@sourceforge.net Tue May 27 01:07:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 17:07:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-672614 ] python -S still displays 'Type "help", "cop...' Message-ID: <E19KRzZ-0005be-00@sc8-sf-web3.sourceforge.net> Bugs item #672614, was opened at 2003-01-22 13:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Douglas Napoleone (derivin) >Assigned to: Martin v. Löwis (loewis) Summary: python -S still displays 'Type "help", "cop...' Initial Comment: $ python -S Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: name 'help' is not defined site.py sets up the builtins for help, credits, etc. where this is printed in Py_Main() it is already known wether or not site.py was going to be imported or not. I know its a real nit-pick, but it has bugged me for some time. should be set to a LOW priority. (and yes, the bug is still there in 2.3a1) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 20:07 Message: Logged In: YES user_id=33168 This was checked in by Martin on 2003/03/30 17:00:39. site.py 1.76 and 1.61.6.3 ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-28 14:52 Message: Logged In: YES user_id=670441 Douglas, I went ahead and made your patch into a diff -c at patch number 695250, since it seemed like you weren't going to get to as quickly as you thought. I would have attached it here, but of course in sourceforge I cannot. ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-01-26 02:31 Message: Logged In: YES user_id=541557 um sure.... its just: if(!Py_NoSiteFlag) { fprintf(stderr, "%s\n" COPYRIGHT); } I'll put up a dicc -c patch on monday after I test it... seen to many patches that dont compile ^_^ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-25 20:08 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=105470&aid=672614&group_id=5470 From noreply@sourceforge.net Tue May 27 02:59:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 18:59:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current Message-ID: <E19KTk3-0000Ip-00@sc8-sf-web3.sourceforge.net> Bugs item #740234, was opened at 2003-05-20 03:50 Message generated for change (Comment added) made by tpx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Till Plewe (tpx) Assigned to: Nobody/Anonymous (nobody) Summary: test/build-failures on FreeBSD stable/current Initial Comment: Using snapshot: python_2003-05-19_230000.tar.gz STABLE (FreeBSD 4.8-STABLE #14: Mon Apr 7) CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue May 20) BUILDFAILURE curses does not build; neither on CURRENT nor on STABLE (compiler complaint: /usr/include/ncurses.h:289: conflicting types for `wchar_t' /usr/include/stdlib.h:57: previous declaration of `wchar_t' /usr/include/ncurses.h:292: conflicting types for `wint_t' /usr/include/wchar.h:96: previous declaration of `wint_t' if lines /usr/include/ncurses.h:288-293 #ifndef __wchar_t typedef unsigned long wchar_t; #endif /* __wchar_t */ #ifndef __wint_t typedef long int wint_t; #endif /* __wint_t */ are deleted then curses builds) TESTFAILURES test_re fails on both CURRENT and STABLE test_long test_pow and many more (probably related) tests fail on current See attached file for details ---------------------------------------------------------------------- >Comment By: Till Plewe (tpx) Date: 2003-05-27 01:59 Message: Logged In: YES user_id=782552 it seems that test_stack_overflow is the culprit ... def test_stack_overflow(self): # nasty case that overflows the straightforward recursive # implementation of repeated groups. self.assertRaises(RuntimeError, re.match, '(x)*', 50000*'x') self.assertRaises(RuntimeError, re.match, '(x)*y', 50000*'x'+'y') self.assertRaises(RuntimeError, re.match, '(x)*?y', 50000*'x'+'y') ... >>> A.test_stack_overflow() Process Python bus error (core dumped) Python 2.3b1+ (#1, May 20 2003, 11:38:20) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.match('(x)*', 5000*'x') <_sre.SRE_Match object at 0x81d2b20> >>> re.match('(x)*', 50000*'x') Process Python bus error (core dumped) Python 2.3b1+ (#1, May 20 2003, 11:38:20) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.match('(x)*y', 5000*'x'+'y') <_sre.SRE_Match object at 0x81523a0> >>> re.match('(x)*y', 50000*'x'+'y') Process Python bus error (core dumped) Python 2.3b1+ (#1, May 20 2003, 11:38:20) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.match('(x)*?y', 5000*'x'+'y') <_sre.SRE_Match object at 0x81523a0> >>> re.match('(x)*?y', 50000*'x'+'y') Process Python bus error (core dumped) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 23:40 Message: Logged In: YES user_id=33168 Can you determine what the conflict in the header files which prevents curses from building? My guess is that test_bug_418626() is causing the core dump (from test_re.py). Can you verify the problem is in that function? If so, can you test each of the re.match/re.search in the interpreter to determine which line is failling? My guess is that it's related to the recursion limit (likely the last line). Your stack size limit may be too small for the python recursion limit. You can try doing a ulimit -a to see all the limits. ulimit -s 8192 is what my stack size is set to (but on Linux). Doing that command may work for you. But this is all conjecture until you investigate further. ---------------------------------------------------------------------- Comment By: Till Plewe (tpx) Date: 2003-05-22 05:04 Message: Logged In: YES user_id=782552 Most of the test failures on FreeBSD CURRENT seem to be gcc bugs. (I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release)) Rebuilding world with the additional compiler flag -mno-sse2 got rid of most test failures. Now only the curses build failure and the test_re failure remain. ---------------------------------------------------------------------- Comment By: Till Plewe (tpx) Date: 2003-05-22 04:57 Message: Logged In: YES user_id=782552 I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release). Most of the test failures seem to be gcc-bugs. Rebuilding world with the extra compiler flag -mno-sse2 got rid of most test failures. Now only the test_re failure and the curses build failure remain. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 22:34 Message: Logged In: YES user_id=33168 I think many of the failures are due to the test_long failure. If that problem is fixed, my guess is several other tests will start working. What compiler are you using? Can you try to debug the test_long failure? I don't think any python developers have access to a freebsd box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 From noreply@sourceforge.net Tue May 27 03:37:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 19:37:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current Message-ID: <E19KUKy-0005iV-00@sc8-sf-web1.sourceforge.net> Bugs item #740234, was opened at 2003-05-20 03:50 Message generated for change (Comment added) made by tpx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Till Plewe (tpx) Assigned to: Nobody/Anonymous (nobody) Summary: test/build-failures on FreeBSD stable/current Initial Comment: Using snapshot: python_2003-05-19_230000.tar.gz STABLE (FreeBSD 4.8-STABLE #14: Mon Apr 7) CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue May 20) BUILDFAILURE curses does not build; neither on CURRENT nor on STABLE (compiler complaint: /usr/include/ncurses.h:289: conflicting types for `wchar_t' /usr/include/stdlib.h:57: previous declaration of `wchar_t' /usr/include/ncurses.h:292: conflicting types for `wint_t' /usr/include/wchar.h:96: previous declaration of `wint_t' if lines /usr/include/ncurses.h:288-293 #ifndef __wchar_t typedef unsigned long wchar_t; #endif /* __wchar_t */ #ifndef __wint_t typedef long int wint_t; #endif /* __wint_t */ are deleted then curses builds) TESTFAILURES test_re fails on both CURRENT and STABLE test_long test_pow and many more (probably related) tests fail on current See attached file for details ---------------------------------------------------------------------- >Comment By: Till Plewe (tpx) Date: 2003-05-27 02:37 Message: Logged In: YES user_id=782552 I forgot to mention that stack size is probably not the problem (FreeBSD 5.1 and 4.8 behave identical with respect to test_re.py) ==================================== FreeBSD 4.8-STABLE FreeBSD 4.8-STABLE #14: Mon Apr 7 17:43:45 JST 2003 i386 + ulimit -a cpu time (seconds, -t) unlimited file size (512-blocks, -f) unlimited data seg size (kbytes, -d) 524288 stack size (kbytes, -s) 65536 core file size (512-blocks, -c) unlimited max memory size (kbytes, -m) unlimited locked memory (kbytes, -l) unlimited max user processes (-u) 896 open files (-n) 1792 virtual mem size (kbytes, -v) unlimited sbsize (bytes, -b) unlimited ================================================================ FreeBSD 5.1-BETA FreeBSD 5.1-BETA #25: Thu May 22 09:10:55 JST 2003 i386 + ulimit -a cpu time (seconds, -t) unlimited file size (512-blocks, -f) unlimited data seg size (kbytes, -d) 1572864 stack size (kbytes, -s) 1572864 core file size (512-blocks, -c) unlimited max memory size (kbytes, -m) unlimited locked memory (kbytes, -l) unlimited max user processes (-u) 5547 open files (-n) 11095 virtual mem size (kbytes, -v) unlimited sbsize (bytes, -b) unlimited ---------------------------------------------------------------------- Comment By: Till Plewe (tpx) Date: 2003-05-27 01:59 Message: Logged In: YES user_id=782552 it seems that test_stack_overflow is the culprit ... def test_stack_overflow(self): # nasty case that overflows the straightforward recursive # implementation of repeated groups. self.assertRaises(RuntimeError, re.match, '(x)*', 50000*'x') self.assertRaises(RuntimeError, re.match, '(x)*y', 50000*'x'+'y') self.assertRaises(RuntimeError, re.match, '(x)*?y', 50000*'x'+'y') ... >>> A.test_stack_overflow() Process Python bus error (core dumped) Python 2.3b1+ (#1, May 20 2003, 11:38:20) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.match('(x)*', 5000*'x') <_sre.SRE_Match object at 0x81d2b20> >>> re.match('(x)*', 50000*'x') Process Python bus error (core dumped) Python 2.3b1+ (#1, May 20 2003, 11:38:20) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.match('(x)*y', 5000*'x'+'y') <_sre.SRE_Match object at 0x81523a0> >>> re.match('(x)*y', 50000*'x'+'y') Process Python bus error (core dumped) Python 2.3b1+ (#1, May 20 2003, 11:38:20) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.match('(x)*?y', 5000*'x'+'y') <_sre.SRE_Match object at 0x81523a0> >>> re.match('(x)*?y', 50000*'x'+'y') Process Python bus error (core dumped) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 23:40 Message: Logged In: YES user_id=33168 Can you determine what the conflict in the header files which prevents curses from building? My guess is that test_bug_418626() is causing the core dump (from test_re.py). Can you verify the problem is in that function? If so, can you test each of the re.match/re.search in the interpreter to determine which line is failling? My guess is that it's related to the recursion limit (likely the last line). Your stack size limit may be too small for the python recursion limit. You can try doing a ulimit -a to see all the limits. ulimit -s 8192 is what my stack size is set to (but on Linux). Doing that command may work for you. But this is all conjecture until you investigate further. ---------------------------------------------------------------------- Comment By: Till Plewe (tpx) Date: 2003-05-22 05:04 Message: Logged In: YES user_id=782552 Most of the test failures on FreeBSD CURRENT seem to be gcc bugs. (I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release)) Rebuilding world with the additional compiler flag -mno-sse2 got rid of most test failures. Now only the curses build failure and the test_re failure remain. ---------------------------------------------------------------------- Comment By: Till Plewe (tpx) Date: 2003-05-22 04:57 Message: Logged In: YES user_id=782552 I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release). Most of the test failures seem to be gcc-bugs. Rebuilding world with the extra compiler flag -mno-sse2 got rid of most test failures. Now only the test_re failure and the curses build failure remain. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 22:34 Message: Logged In: YES user_id=33168 I think many of the failures are due to the test_long failure. If that problem is fixed, my guess is several other tests will start working. What compiler are you using? Can you try to debug the test_long failure? I don't think any python developers have access to a freebsd box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470 From noreply@sourceforge.net Tue May 27 06:51:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 22:51:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-744051 ] sum() should be renamed Message-ID: <E19KXMd-00078G-00@sc8-sf-web3.sourceforge.net> Bugs item #744051, was opened at 2003-05-27 05: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=744051&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: sum() should be renamed Initial Comment: 1. "sum" is a commonly used name for variables and functions at both the global and local levels. 2. from Numeric import * (as recommended by Alex Martelli in Python in a Nutshell) will shadow the new builtin resulting in changed behavior for any functions using it. In theory, namespaces make the problem irrelevant. In practice, it creates hard-to-find errors. The conflict between __builtin__.open and os.open has been a small disaster. To a lesser degree, __builtin__.pow and math.pow have a conflict. It is not too late to fix this by choosing a less commonly used name: summation, addall, addsequence, sigma, sumsequence, addit or anything that isn't already being used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744051&group_id=5470 From noreply@sourceforge.net Tue May 27 11:22:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 03:22:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-744164 ] ipv6 addrinfo is bad Message-ID: <E19KbbD-0006s5-00@sc8-sf-web1.sourceforge.net> Bugs item #744164, was opened at 2003-05-27 10: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=744164&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: cypherpunks (cypherpunks) Assigned to: Nobody/Anonymous (nobody) Summary: ipv6 addrinfo is bad Initial Comment: ipv6 addrinfo becomes a 4-tuple in python, with additional scope-id and flowinfo members that are never used in practice by normal apps. scope id might be used once in a blue moon by something like a dhcp server (use link local addresses). this difference causes a large portion of work involved in porting python apps to suppot v6. i suggest it be changed to just an address-port tuple, or add some kind of hack to allow it ot be unpacked like "host, port = addr". -- erno kuusela <erno@iki.fi> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744164&group_id=5470 From noreply@sourceforge.net Tue May 27 15:11:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 07:11:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-731635 ] Package Manager needs Help menu Message-ID: <E19KfAT-0006OD-00@sc8-sf-web2.sourceforge.net> Bugs item #731635, was opened at 2003-05-03 00:58 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731635&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Package Manager needs Help menu Initial Comment: The standalone Package Manager needs a help menu, pointing to Package Manager section in MacPython help. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-27 16:11 Message: Logged In: YES user_id=45365 Fixed in PackageManager.py 1.10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731635&group_id=5470 From noreply@sourceforge.net Tue May 27 15:45:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 07:45:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-620412 ] Max recursion limit with "*?" pattern Message-ID: <E19Kfi2-0008Nm-00@sc8-sf-web2.sourceforge.net> Bugs item #620412, was opened at 2002-10-08 19:40 Message generated for change (Settings changed) made by thorstein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620412&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Max recursion limit with "*?" pattern Initial Comment: I ran into the following problem trying to parse an ms outlook mail box. Cut down to its bare essentials: > cat tst.py import re mstr = (11000*' ') + 'A' pattern = re.compile('.*?A') pattern.search(mstr) > python tst.py Traceback (most recent call last): File "tst.py", line 5, in ? pattern.search(mstr) RuntimeError: maximum recursion limit exceeded > python Python 2.2.1c1 (#6, Jul 20 2002, 09:40:07) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> The combination of a longish string with ".*?" gives the error. Using ".*" is ok. Could "non-greedy" matching be implemented non-recursively? If I understand correctly, the limit exceeded is USE_RECURSION_LIMIT in Modules/_sre.c. It is slightly confusing because we also have the Python recursion limit (my first reaction was to bump it up with sys.setrecursionlimit(), but that of course didn't help). ---------------------------------------------------------------------- >Comment By: Thorstein Thorsteinsson (thorstein) Date: 2003-05-27 14:45 Message: Logged In: YES user_id=587322 I've tried my example with Python 2.3, and the error has disappeared. So as far as I'm concerned, this bug reported can be deleted. Thanks. Thorstein ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-05-24 16:49 Message: Logged In: YES user_id=7887 As Gary Herron correctly pointed me out, this was fixed in 2.3 with the introduction of a new opcode to handle single character non-greedy matching. This won't be fixed in 2.2.3, but hopefully will be backported to 2.2.4 together with other regular expression fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620412&group_id=5470 From noreply@sourceforge.net Tue May 27 16:02:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 08:02:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-724621 ] email/quopriMIME.py exception on int (lstrip) Message-ID: <E19Kfxq-0007Iw-00@sc8-sf-web4.sourceforge.net> Bugs item #724621, was opened at 2003-04-20 11:36 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Moshe Yudkowsky (myudkowsky) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/quopriMIME.py exception on int (lstrip) Initial Comment: Python 2.3a2+, Debian Summary: when I use the as_string() method on a multipart, multilevel message, I get an exception from email/quopriMIME.py, line 84, complaining about lstrip() of an integer. Initial condtions: I have a script that reads an email message, extracts some information, encapsulates the message and then forwards it with some commentary. This script works under Python 2.2.2. Failure: This script does not run under 2.3a2+ -- it fails on the as_string() method. In particular, at the file/lineno given above. Using the debugger, I see that in fact there *is* an integer at that point, the digit "1" to be exact. Looking up in the stack, I see that this function was called by the method _encode_chunks in Headers.py, and that the "newchunks" was [ (1, us-ascii ) ]. Please let me know if you need copies of the scripts, email messages, etc. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-27 11:02 Message: Logged In: YES user_id=12800 You're going to kick yourself. :) Look carefully at your code, where you assign values to the Content-Length and Lines headers in the inner spam message. You're setting those values to integers -- they have to be strings. If I wrap the values in str() it all works for me. ---------------------------------------------------------------------- Comment By: Moshe Yudkowsky (myudkowsky) Date: 2003-05-26 10:26 Message: Logged In: YES user_id=288768 I have deleted the original file, in which I'd accidentally left my email address, and replaced it with an anonymized version. ---------------------------------------------------------------------- Comment By: Moshe Yudkowsky (myudkowsky) Date: 2003-05-26 00:14 Message: Logged In: YES user_id=288768 Now, of course, I'm having trouble generating the exact same error. The enclosed script WFM under 2.2.2, but fails under 2.3b1+. The fault still seems to lie with "newchunks" but now the failure comes from Charset.py: Traceback (most recent call last): File "mailfail.py", line 203, in ? outMailString = wrapper.as_string() File "/usr/lib/python2.3/email/Message.py", line 113, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 130, in _write self._dispatch(msg) File "/usr/lib/python2.3/email/Generator.py", line 156, in _dispatch meth(msg) File "/usr/lib/python2.3/email/Generator.py", line 230, in _handle_multipart g.flatten(part, unixfrom=False) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 130, in _write self._dispatch(msg) File "/usr/lib/python2.3/email/Generator.py", line 156, in _dispatch meth(msg) File "/usr/lib/python2.3/email/Generator.py", line 297, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/usr/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/lib/python2.3/email/Generator.py", line 137, in _write self._write_headers(msg) File "/usr/lib/python2.3/email/Generator.py", line 183, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/lib/python2.3/email/Header.py", line 412, in encode newchunks += self._split(s, charset, targetlen, splitchars) File "/usr/lib/python2.3/email/Header.py", line 297, in _split elen = charset.encoded_header_len(encoded) File "/usr/lib/python2.3/email/Charset.py", line 341, in encoded_header_len return len(s) I can either continue to try and recreate the original error, or if this is sufficient information to debug I'll stop now. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 16:00 Message: Logged In: YES user_id=12800 Moving to Pending, waiting on more information. In 14 days, if there's no follow up this bug report will be automatically closed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-15 10:08 Message: Logged In: YES user_id=12800 Yes, please upload (not paste) all relevant files needed for me to reproduce the problem. Please boil down your example as much as possible, but be sure to include a complete example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=724621&group_id=5470 From noreply@sourceforge.net Tue May 27 18:43:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 10:43:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-742860 ] WeakKeyDictionary __delitem__ uses iterkeys Message-ID: <E19KiU6-0001Mr-00@sc8-sf-web2.sourceforge.net> Bugs item #742860, was opened at 2003-05-24 16:24 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakKeyDictionary __delitem__ uses iterkeys Initial Comment: iterkeys will raise a RuntimeError if the size of the dictionary changes during iteration. Deleting items from the dictionary may cause cascade deletions which will change the dictionary size. Possible solutions: Use keys instead of iterkeys: line 155 of weakref.py: for ref in self.data.keys(): Document the possibility that __delitem__ will raise RuntimeErrors (not a preferable solution). Note that there is also a potential race condition in the __delitem__ method, where the key is del'd from the data dictionary without a try: except: to catch cases where the key is deleted between the time the key is retrieved and the time the deletion occurs (which is more likely if keys is used, but could still happen with iterkeys). Same problem is seen in both 2.2.2 and 2.2.3 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-27 13:43 Message: Logged In: YES user_id=34901 Can't test 2.3 CVS just now (don't want to mess up the works while I'm debugging a wxPython bug). The one-liner: def __delitem__(self, key): del self.data[ref(key)] does appear to work under Python 2.2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 21:47 Message: Logged In: YES user_id=31435 Mike, can you try current CVS Python (2.3)? Fred won't be back for days, so I can't quiz him. I implemented the one- liner __delitem__, which is much faster, can't raise RuntimeError, and should be better behaved in all respects in the face of threads and/or comparison functions that mutate the dict as a side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 21:30 Message: Logged In: YES user_id=31435 Ah, threads. OK, but if two threads both try to delete the same key, then one of them *should* see a KeyError -- same as for a regular dict. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-24 20:58 Message: Logged In: YES user_id=34901 Re: race condition. Thread 1 calls del d[x] and then thread 2 calls del d[x]. Both have strong refs to the key, so the weakrefs don't die, both get the list of keys (weakrefs) to scan before either deletes a key, both then try to delete the item from the data dictionary. That is: t1: del d[x] t2: del d[x] t1: gets keys() t2: gets keys() t1: finds key in keys, does del data[ref] t2: finds key in keys (even though it's no longer in the dictionary), tries to do del data[ref], raises KeyError because t1 has already removed the weakref key from the data dictionary. I may be wrong, of course. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 20:36 Message: Logged In: YES user_id=31435 In staring at the code, I'm baffled as to why __delitem__ iterates over the keys at all. Why isn't the implementation the one-liner del self.data[ref(key)] ? That's basically what __contains__, has_key() and __getitem__ get away with. Two refs to the same object have the same hash codes and compare equal, so I'm having a hard time seeing why that isn't good enough for __delitem__ too. Mike, I didn't understand your point about the race condition. The object passed to __delitem__ as the key has a strong reference to it merely by virtue of having been passed to __delitem__, so it can't go away until (at earliest) __delitem__ returns (and so drops its strong reference to key). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:50 Message: Logged In: YES user_id=31435 Assigned to Fred (the original author, IIRC), and boosted priority a notch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 From noreply@sourceforge.net Tue May 27 18:51:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 10:51:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-744051 ] sum() should be renamed Message-ID: <E19KibZ-0001qL-00@sc8-sf-web2.sourceforge.net> Bugs item #744051, was opened at 2003-05-27 01:51 Message generated for change (Comment added) made by sbronson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744051&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: sum() should be renamed Initial Comment: 1. "sum" is a commonly used name for variables and functions at both the global and local levels. 2. from Numeric import * (as recommended by Alex Martelli in Python in a Nutshell) will shadow the new builtin resulting in changed behavior for any functions using it. In theory, namespaces make the problem irrelevant. In practice, it creates hard-to-find errors. The conflict between __builtin__.open and os.open has been a small disaster. To a lesser degree, __builtin__.pow and math.pow have a conflict. It is not too late to fix this by choosing a less commonly used name: summation, addall, addsequence, sigma, sumsequence, addit or anything that isn't already being used. ---------------------------------------------------------------------- Comment By: Samuel Bronson (sbronson) Date: 2003-05-27 13:51 Message: Logged In: YES user_id=237753 The locals are not a big problem, as long as functions are a reasonable size. Is sum really that common at the global level? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744051&group_id=5470 From noreply@sourceforge.net Tue May 27 22:43:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 14:43:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-734695 ] Function for creating/extracting CoreFoundation types Message-ID: <E19KmEJ-0001G0-00@sc8-sf-web4.sourceforge.net> Bugs item #734695, was opened at 2003-05-08 17:15 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Function for creating/extracting CoreFoundation types Initial Comment: pymactoolbox.h contains a number of functions for converting from CoreFoundation references to Python wrappers for those functions (e.g. CFTypeRefObj_New). Simularly there are functions for extracting the CoreFoundation reference from a wrapped Python object (e.g. CFTypeRefObj_Convert). It would be nice if CFTypeRefObj_New would automaticly create a more specialized Python wrapper if you pass it a CFArrayRef, this decreases the coupling between the python core and 3th party extension modules. Simularly CFTypeRefObj_Convert should "work" when passed a CFArrayRefObj. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-27 23:43 Message: Logged In: YES user_id=45365 Implemented in CVS, but I have called the new generalized functions CFObj_New() and CFObj_Convert(). One issue is open to discussion: currently CFObj_New() expects a CFTypeRef object for which a wrapper is available. An alternative would be to use PyCF_CF2Python() otherwise (so CFNumber would get mapped to a Python int, etc). Similarly for CFObj_Convert(), which expects an object of one of the classes Carbon.CF implements. It could also fall back to using PyCF_Python2CF(). Let me know which solution is better. Also: the code is pretty much untested. Please test, and close this report when you're satisfied (and after answering the previous question). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 From noreply@sourceforge.net Wed May 28 01:42:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 17:42:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-693094 ] Python does not build --with-pydebug on Tru64 with vendor cc Message-ID: <E19Kp1m-0002lI-00@sc8-sf-web2.sourceforge.net> Bugs item #693094, was opened at 2003-02-25 11:48 Message generated for change (Comment added) made by sfiedler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470 Category: Build Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Stephan A. Terre (sfiedler) Assigned to: Neal Norwitz (nnorwitz) Summary: Python does not build --with-pydebug on Tru64 with vendor cc Initial Comment: The default standards-compliance level for the Compaq/HP compiler defines the assert macro using the if statement (if...then) rather than the ternary if expression (?:). As a result, when Python is configured --with-pydebug (so NDEBUG is not defined), the macro Py_SAFE_DOWNCAST expands to illegal C (containing a statement inside an expression). This can be fixed by asserting the -std switch to the vendor compiler. Testing of 2.2.2 CVS and 2.3 CVS indicates that there is no bad side effect to asserting -std. I hope to develop a fix for this in configure.in sometime in the next couple of days. When I have done so, I will attach it to this bug. For the record, here are the variations of the -std switch on the vendor compiler: -std0 Selects the K & R language mode. This is the default. Enforces the K & R programming style, with certain ANSI extensions in areas where the K & R behavior is undefined or ambiguous. In general, -std0 compiles most pre-ANSI C programs and produces expected results. The -std0 option causes the __STDC__ macro to be undefined. -std Selects the relaxed ANSI language mode. Enforces the ANSI C standard, but allows some common programming practices disallowed by the stan- dard. This option does not restrict the Tru64 UNIX name space (for example, the names defined in system header files). To restrict that name space so that only ANSI C reserved names are visible from the ANSI C header files, use the _ANSI_C_SOURCE macro. See standards(5) for more details. This option causes the macro __STDC_ to be defined to 0. -std1 Selects the strict ANSI language mode. Strictly enforces the ANSI C standard and all its prohibitions (such as those that apply to the han- dling of void types, the definition of lvalues in expressions, the mix- ing of integrals and pointers, and the modification of rvalues). This option does not restrict the Tru64 UNIX name space (for example, the names defined in system header files). To restrict that name space so that only ANSI C reserved names are visible from the ANSI C header files, use the _ANSI_C_SOURCE macro. See standards(5) for more details. This option causes the macro __STDC_ to be defined to 1. Note that this option also affects linker-defined symbols. See ld(1) for more infor- mation. This option turns on ANSI aliasing rules (-ansi_alias option). ---------------------------------------------------------------------- >Comment By: Stephan A. Terre (sfiedler) Date: 2003-05-27 17:42 Message: Logged In: YES user_id=246063 The good news is that unicodeobject.c now builds properly, because of the -std flag to the compiler. Unfortunately, there is still a problem with getpgrp/setpgrp. Here is the error: cc: Error: ./Modules/posixmodule.c, line 2730: In this statement, "getpgrp" expects 0 arguments, but 1 are supplied. (toomanyargs) return PyInt_FromLong((long)getpgrp(0)); ------------------------------------^ This is problem (2) from my followup of 2-27-2003. The apparent problem is that HP's Tru64 compiler gives a different signature to getpgrp depending on whether or not -std is asserted; when the test for what signature is expected is done without -std, but the actual build of posixmodule is done with -std, then there is a mismatch. What I had suggested before was changing the compiler used for subsequent tests to include all the flags that we had discovered were needed, so that tests were done with the same flags that would be used during build. If this is too radical, perhaps just the test for getpgrp's signature could use this technique? ---------------------------------------------------------------------- Comment By: Stephan A. Terre (sfiedler) Date: 2003-05-26 11:11 Message: Logged In: YES user_id=246063 I'll try the fix tomorrow when I am at work and have access to a Tru64 machine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 07:16 Message: Logged In: YES user_id=33168 Checked in as: * configure 1.402 * configure.in 1.413 Please test the current CVS. It was a little different from the patch here. I think it should work though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 09:46 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Stephan A. Terre (sfiedler) Date: 2003-02-27 17:58 Message: Logged In: YES user_id=246063 Attached to this bug is a patch to configure.in and configure. I believe pretty much all of the three decisions I made need review :) 1. I put the -std flag in BASECFLAGS an OSF1-specific case in the non-gcc branch. Should there be some other check here that we're using the vendor C compiler? If so, can anyone point me at an example? 2. Upon testing, I found that the getpgrp function has a different signature when compiled with -std than without. As a result, the posixmodule didn't build. My solution was to change the definition of CC in configure.in to be "$CC $BASECFLAGS $OPT" after the last change to OPT and BASECFLAGS. My thinking is that we ought to be running feature and behavior tests with the flags that we'll be using to build the interpreter. However, if this goes against the spirit or policy of autoconf, we should do something else! 3. I happened to notice an XXX about Monterey, so I did a little investigation and added to the note. Hopefully this is not a gaffe. I have tested the changes to configure.in on Tru64 4.0F both with and without the --with-pydebug flag to configure. The test suite behaved the same in each case as before my mods. I also tested the changes --with-pydebug on a Red Hat 7 system; they seemed good there too. If I should have put this patch in the Patch Manager rather than attaching to the bug directly, I apologize and promise never to do it wrongly again :) Please let me know by posting a followup here or via email if there is anything else I should do for this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470 From noreply@sourceforge.net Wed May 28 04:07:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 20:07:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-744687 ] anydbm and whichdb again Message-ID: <E19KrHe-00040F-00@sc8-sf-web1.sourceforge.net> Bugs item #744687, was opened at 2003-05-28 13: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=744687&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Saunders (grerfy) Assigned to: Nobody/Anonymous (nobody) Summary: anydbm and whichdb again Initial Comment: There is an annoying inconsistency with the various dbm modules that occurs when a database is created, left empty, and then re-opened for writing later with anydbm. Code to produce the bug appears below: Python 2.2.2 (#1, Mar 21 2003, 23:01:54) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import dbhash, gdbm, dumbdbm, anydbm >>> a = dbhash.open('/tmp/a', 'c') >>> a.close() >>> a1 = anydbm.open('/tmp/a', 'w') >>> a1.close() >>> b = gdbm.open('/tmp/b', 'c') >>> b.close() >>> b1 = anydbm.open('/tmp/b', 'w') >>> b1.close() >>> c = dumbdbm.open('/tmp/c', 'c') >>> c.close() >>> c1 = anydbm.open('/tmp/c', 'w') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/anydbm.py", line 80, in open raise error, "need 'c' or 'n' flag to open new db" anydbm.error: need 'c' or 'n' flag to open new db >>> I have also tried this on python2.3b1, and python2.1.3 - with the same results. The bug occurs apparently because the whichdb module cannot properly identify an empty dumbdbm file. So, the bug also occurs in this example: Python 2.2.2 (#1, Mar 21 2003, 23:01:54) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import dumbdbm, anydbm >>> a = dumbdbm.open('aaa', 'c') >>> a['abc'] = 'def' >>> a.close() >>> b = anydbm.open('aaa', 'w') >>> del b['abc'] >>> b.close() >>> c = anydbm.open('aaa', 'w') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/anydbm.py", line 80, in open raise error, "need 'c' or 'n' flag to open new db" anydbm.error: need 'c' or 'n' flag to open new db >>> One solution to this might be to place a warning in the anydbm documentation that leaving a file empty is invalid. Another possibility is to include some kind of magic in dumbdbm so that whichdb can identify them. A patch for the python2.2.2 dumbdbm.py file is attached. regards Greg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744687&group_id=5470 From noreply@sourceforge.net Wed May 28 04:25:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 20:25:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-744687 ] anydbm and whichdb again Message-ID: <E19KrZ5-0004XS-00@sc8-sf-web1.sourceforge.net> Bugs item #744687, was opened at 2003-05-28 13:07 Message generated for change (Comment added) made by grerfy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744687&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Saunders (grerfy) Assigned to: Nobody/Anonymous (nobody) Summary: anydbm and whichdb again Initial Comment: There is an annoying inconsistency with the various dbm modules that occurs when a database is created, left empty, and then re-opened for writing later with anydbm. Code to produce the bug appears below: Python 2.2.2 (#1, Mar 21 2003, 23:01:54) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import dbhash, gdbm, dumbdbm, anydbm >>> a = dbhash.open('/tmp/a', 'c') >>> a.close() >>> a1 = anydbm.open('/tmp/a', 'w') >>> a1.close() >>> b = gdbm.open('/tmp/b', 'c') >>> b.close() >>> b1 = anydbm.open('/tmp/b', 'w') >>> b1.close() >>> c = dumbdbm.open('/tmp/c', 'c') >>> c.close() >>> c1 = anydbm.open('/tmp/c', 'w') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/anydbm.py", line 80, in open raise error, "need 'c' or 'n' flag to open new db" anydbm.error: need 'c' or 'n' flag to open new db >>> I have also tried this on python2.3b1, and python2.1.3 - with the same results. The bug occurs apparently because the whichdb module cannot properly identify an empty dumbdbm file. So, the bug also occurs in this example: Python 2.2.2 (#1, Mar 21 2003, 23:01:54) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import dumbdbm, anydbm >>> a = dumbdbm.open('aaa', 'c') >>> a['abc'] = 'def' >>> a.close() >>> b = anydbm.open('aaa', 'w') >>> del b['abc'] >>> b.close() >>> c = anydbm.open('aaa', 'w') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/anydbm.py", line 80, in open raise error, "need 'c' or 'n' flag to open new db" anydbm.error: need 'c' or 'n' flag to open new db >>> One solution to this might be to place a warning in the anydbm documentation that leaving a file empty is invalid. Another possibility is to include some kind of magic in dumbdbm so that whichdb can identify them. A patch for the python2.2.2 dumbdbm.py file is attached. regards Greg ---------------------------------------------------------------------- >Comment By: Gregory Saunders (grerfy) Date: 2003-05-28 13:25 Message: Logged In: YES user_id=788203 Incidentally, the patch I have attached is designed to work with no modification to the whichdb module. The whichdb module could be modified to check for the correct magic - but this could break backwards compatibility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744687&group_id=5470 From noreply@sourceforge.net Wed May 28 08:59:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 00:59:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-732951 ] bsddb.*open mode should default to 'r' rather than 'c' Message-ID: <E19Kvqg-0006bb-00@sc8-sf-web3.sourceforge.net> Bugs item #732951, was opened at 2003-05-05 15:35 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732951&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Gregory P. Smith (greg) Summary: bsddb.*open mode should default to 'r' rather than 'c' Initial Comment: In module bsddb, the second argument of the open functions (e.g., btopen) should default to 'r' rather than 'c'. Most (all?) of the other open functions, both in the various dbm-like modules and for basic I/O default this way. If this change is not made, then at least this behavior should be documented clearly. Currently it's not documented at all (as far as I can find). Cheers, Mike ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-05-28 00:59 Message: Logged In: YES user_id=413 It appears that the old bsddb library also defaulted to 'r' for the *open() functions. I just committed an update to the libbsddb.tex documentation source that mentions that 'r' is the default. I didn't want to break compatibility with any existing applications. hopefully that documentation update will make it into the 2.3 release. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 13:11 Message: Logged In: YES user_id=12800 That certainly would make it more consistent with other *dbm open functions. I guess you'd want to change hashopen(), btopen(), and rnopen(). OTOH, this probably breaks backward compatibility for those coming from the pybsddb world. Assigning to Greg Smith to make final decision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732951&group_id=5470 From noreply@sourceforge.net Wed May 28 09:05:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 01:05:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-730938 ] Python 2.3 bsddb docs need update Message-ID: <E19Kvvj-00061o-00@sc8-sf-web1.sourceforge.net> Bugs item #730938, was opened at 2003-05-01 11:42 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730938&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Later >Priority: 3 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Gregory P. Smith (greg) Summary: Python 2.3 bsddb docs need update Initial Comment: We need to do /something/ about the bsddb module documentation in Python 2.3. The current docs are for the old bsddb module and they're worse than out-of-date. Ideally, we'd import pybsddb's documentation in Python latex format, and add docs for all the auxiliary modules that come in the bsddb package. If we don't have time for that, we should at least update the docs to point to the pybsddb site and document the list of additional modules. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-05-28 01:05 Message: Logged In: YES user_id=413 I cleaned up my patch and committed the update to the documentation that mentions the modern Db and DbEnv interface with a URL to the pybsddb documentation. That should suffice for now until proper pybsddb documentation can be cleaned up, updated and put in as a TeX of its own. I'm leaving this bug open in the Later state with a low priority to track the inclusion of native Db, DbEnv object documentation. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-01 12:15 Message: Logged In: YES user_id=12800 Taking ownership to review ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-05-01 12:12 Message: Logged In: YES user_id=413 Yes, this is important. I've attached a patch against the current python documentation that points to pybsddb. I've never edited the python latex docs before and am not currently setup for compiling/viewing the updates or verifying that i used the correct syntax. can you review it and check it in if it makes sense? unfortunately even the pybsddb project's documentation is a bit dated (mostly in that several new features/functions have been exposed since it was written) but it is a *much* better starting point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730938&group_id=5470 From noreply@sourceforge.net Wed May 28 09:27:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 01:27:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-727571 ] test_bsddb3 fails Message-ID: <E19KwHn-0002cU-00@sc8-sf-web2.sourceforge.net> Bugs item #727571, was opened at 2003-04-25 09:08 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727571&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Gregory P. Smith (greg) Summary: test_bsddb3 fails Initial Comment: Running regrtest.py -u all with a checkout from this morning at around 11am. Exception in thread reader 3: Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/threading.py", line 411, in __bootstrap self.run() File "/home/jeremy/src/python/dist/src/Lib/threading.py", line 399, in run self.__target(*self.__args, **self.__kwargs) File "/home/jeremy/src/python/dist/src/Lib/bsddb/test/test_thread.py", line 270, in readerThread rec = c.first() DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Exception in thread reader 2: Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/threading.py", line 411, in __bootstrap self.run() File "/home/jeremy/src/python/dist/src/Lib/threading.py", line 399, in run self.__target(*self.__args, **self.__kwargs) File "/home/jeremy/src/python/dist/src/Lib/bsddb/test/test_thread.py", line 270, in readerThread rec = c.first() DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-05-28 01:27 Message: Logged In: YES user_id=413 These "errors" were harmless and to be expected in the threaded db tests. I updated test_thread.py to wrap the c.first and c.next calls that would likely cause them with a check for DBLockDeadLockError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727571&group_id=5470 From noreply@sourceforge.net Wed May 28 12:02:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 04:02:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-744841 ] Python-Profiler bug: Bad call Message-ID: <E19Kygy-0003HT-00@sc8-sf-web1.sourceforge.net> Bugs item #744841, was opened at 2003-05-28 11:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744841&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: Python-Profiler bug: Bad call Initial Comment: There is a timing problem between the call of "call_trace(profile_func,...,'return',...)" and "reset_exc_info" in Pythons main interpreter loop. The main loop first calls "call_trace" (at the end of function execution). With the standard "profile.Profile" profiler this leads to a pop of the current frame from the profiler stack while the current frame is still on the interpreter stack. Then "reset_exc_info" is called. When this call releases an instance with a destructor ("__del__" method), the "call_trace(profile_func,...'call',...)" for the destructor observes the inconsistency between the profiler and the interpreter stack and raises a "Bad call" exception. This exception disables profiling effectively. However, the exception is later ignored (as we are in a destructor) and program execution continues. When the profiling is later finished, all time after the exception is accounted for the last function, that was on top of the profiler stack when profiling was disabled. This can be extremely confusing. The attached script reproduces the problem. Run it through the Python interpreter. When you see an "Exception Bad call ... ignored", the interpreter has the described problem. We observed the problem in Python 2.1.3 (on Linux, Solaris and Windows). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744841&group_id=5470 From noreply@sourceforge.net Wed May 28 17:30:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 09:30:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-745002 ] <> in attrs in sgmllib not handled Message-ID: <E19L3oR-0007U3-00@sc8-sf-web3.sourceforge.net> Bugs item #745002, was opened at 2003-05-28 16: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=745002&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: <> in attrs in sgmllib not handled Initial Comment: Hi folks - This bug is noted in the source code for sgmllib.py, and it finally bit me. If you feed the SGMLParser class text such as <tag attr = "<attrtag> bar </attrtag>">foo</tag> the <attrtag> will be processed as a tag, as well as being recognized as part of the attribute. This is because of the way the end index for the opening tag is computed. As far as I can tell from the HTML 4.01 specification, this is legal. The case I encountered was in a value of an "onmouseover" attribute, which was a Javascript call which contained HTML text as one of its arguments. The problem is in SGMLParser.parse_starttag, which attempts to compute the end of the opening tag with a simple regexp [<>], and uses this index even when the attributes have passed it. There's no real need to check this regexp in advance, as far as I can tell. I've attached my proposed modification of SGMLParser.parse_starttag; I've tested this change in 2.2.1, but there are no relevant differences between 2.2.1 and the head of the CVS tree for this method. No guarantees of correctness, but it works on the examples I've tested it on. Cheers - Sam Bayer ================================ w_endbracket = re.compile("\s*[<>]") class SGMLParser: # Internal -- handle starttag, return length or -1 if not terminated def parse_starttag(self, i): self.__starttag_text = None start_pos = i rawdata = self.rawdata if shorttagopen.match(rawdata, i): # SGML shorthand: <tag/data/ == <tag>data</tag> # XXX Can data contain &... (entity or char refs)? # XXX Can data contain < or > (tag characters)? # XXX Can there be whitespace before the first /? match = shorttag.match(rawdata, i) if not match: return -1 tag, data = match.group(1, 2) self.__starttag_text = '<%s/' % tag tag = tag.lower() k = match.end(0) self.finish_shorttag(tag, data) self.__starttag_text = rawdata[start_pos:match.end(1) + 1] return k # Now parse the data between i+1 and the end of the tag into a tag and attrs attrs = [] if rawdata[i:i+2] == '<>': # SGML shorthand: <> == <last open tag seen> k = i + 1 tag = self.lasttag else: match = tagfind.match(rawdata, i+1) if not match: self.error('unexpected call to parse_starttag') k = match.end(0) tag = rawdata[i+1:k].lower() self.lasttag = tag while w_endbracket.match(rawdata, k) is None: match = attrfind.match(rawdata, k) if not match: break attrname, rest, attrvalue = match.group(1, 2, 3) if not rest: attrvalue = attrname elif attrvalue[:1] == '\'' == attrvalue[-1:] or \ attrvalue[:1] == '"' == attrvalue[-1:]: attrvalue = attrvalue[1:-1] attrs.append((attrname.lower(), attrvalue)) k = match.end(0) match = endbracket.search(rawdata, k) if not match: return -1 j = match.start(0) if rawdata[j] == '>': j = j+1 self.__starttag_text = rawdata[start_pos:j] self.finish_starttag(tag, attrs) return j ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&group_id=5470 From noreply@sourceforge.net Wed May 28 18:55:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 10:55:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-745055 ] Memory leak in _tkinter.c/Tkapp_SplitList() Message-ID: <E19L59R-0004aZ-00@sc8-sf-web1.sourceforge.net> Bugs item #745055, was opened at 2003-05-28 17:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toni Leppäkorpi (leppako) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in _tkinter.c/Tkapp_SplitList() Initial Comment: Splitlist() function leaks any string given to it as a parameter. This code should reproduce the problem: import Tkinter b = Tkinter.Button(text='Leak', command=lambda:b.tk.splitlist('1 2 {3 4} 5 '*10000)) b.pack() b.mainloop() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 From noreply@sourceforge.net Wed May 28 19:34:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 11:34:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-745055 ] Memory leak in _tkinter.c/Tkapp_SplitList() Message-ID: <E19L5kv-00055C-00@sc8-sf-web3.sourceforge.net> Bugs item #745055, was opened at 2003-05-28 13:55 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toni Leppäkorpi (leppako) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in _tkinter.c/Tkapp_SplitList() Initial Comment: Splitlist() function leaks any string given to it as a parameter. This code should reproduce the problem: import Tkinter b = Tkinter.Button(text='Leak', command=lambda:b.tk.splitlist('1 2 {3 4} 5 '*10000)) b.pack() b.mainloop() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 14:34 Message: Logged In: YES user_id=33168 Funny, I thought I had posted a patch about this. Could you test the attached patch which is against the CVS version? It shouldn't be hard to apply to 2.2.2/2.2.3 either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 From noreply@sourceforge.net Wed May 28 19:54:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 11:54:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-745097 ] urllib2 doesn't handle urls without scheme Message-ID: <E19L63u-0000SI-00@sc8-sf-web2.sourceforge.net> Bugs item #745097, was opened at 2003-05-28 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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470 From noreply@sourceforge.net Wed May 28 19:58:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 11:58:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-731626 ] Pimp needs to be able to update itself Message-ID: <E19L685-0000gp-00@sc8-sf-web2.sourceforge.net> Bugs item #731626, was opened at 2003-05-03 00:16 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731626&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Pimp needs to be able to update itself Initial Comment: Pimp needs a way to update itself. The version number in the database is good enough for backward compatibility (i.e. a newer pimp that happens upon an older database) but not for updating, I think (an older pimp that comes across a database that is too new). A possible solution would be analogous to what Apple does with Software Update: encode the pimp version number in the URL of the database, and when pimp is updated the old database is replaced by one that only offers one choice: upgrade pimp. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-05-28 20:58 Message: Logged In: YES user_id=45365 Fixed in pimp rev 1.22. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731626&group_id=5470 From noreply@sourceforge.net Wed May 28 21:11:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 13:11:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-745145 ] xml.sax Contenthandler passes truncated data Message-ID: <E19L7GO-00023C-00@sc8-sf-web1.sourceforge.net> Bugs item #745145, was opened at 2003-05-28 22: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=745145&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido Treutwein (gtreutwein) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax Contenthandler passes truncated data Initial Comment: Error-Message in Python xml.sax module writeXml_1 generates a xml file ('testOut.xml' )containing random strings and checksums 'readXml_2 testOut.xml' reads the file and verifies the checksums Observation: readXml_2 reports checksum errors. The error occurs on all tried combinations of (Win2000, Win98 and OpenBSD 3.2) with (Python 2.2.2 and 2.3a1). The corrupted strings reported are located shortly before 64kByte boundaries in the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745145&group_id=5470 From noreply@sourceforge.net Wed May 28 22:47:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 14:47:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-745055 ] Memory leak in _tkinter.c/Tkapp_SplitList() Message-ID: <E19L8li-00054L-00@sc8-sf-web1.sourceforge.net> Bugs item #745055, was opened at 2003-05-28 17:55 Message generated for change (Comment added) made by leppako You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 Category: Tkinter Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Toni Leppäkorpi (leppako) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in _tkinter.c/Tkapp_SplitList() Initial Comment: Splitlist() function leaks any string given to it as a parameter. This code should reproduce the problem: import Tkinter b = Tkinter.Button(text='Leak', command=lambda:b.tk.splitlist('1 2 {3 4} 5 '*10000)) b.pack() b.mainloop() ---------------------------------------------------------------------- >Comment By: Toni Leppäkorpi (leppako) Date: 2003-05-28 21:47 Message: Logged In: YES user_id=788774 Good work nnorwitz. Problem solved. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 18:34 Message: Logged In: YES user_id=33168 Funny, I thought I had posted a patch about this. Could you test the attached patch which is against the CVS version? It shouldn't be hard to apply to 2.2.2/2.2.3 either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 From noreply@sourceforge.net Wed May 28 23:16:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 15:16:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19L9Dx-0003As-00@sc8-sf-web2.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-28 18:16 Message: Logged In: YES user_id=6380 Tim, let's look at this when you're back in the office. My head spins from just reading the analysis below. Note that this is a 2.2 and 2.3 bug. I don't necessarily want to hold up the 2.2.3 release until this is fixed, unless we have a quick breakthrough. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 00:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Thu May 29 00:26:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 16:26:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19LAJ4-0000OP-00@sc8-sf-web1.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-28 19:26 Message: Logged In: YES user_id=31435 That's cool. The analysis is much easier to follow if you run Neal's little program, which crashes right away in a debug build. Then the analysis just follows the call stack, and it's instantly obvious (if you know to look for it <wink>) that we're trying to deallocate a single object twice. One thing subtype_delloc does that instance_dealloc doesn't is clear the instance dict before clearing the weakrefs. Clearing the instance dict can end up executing anything, and in this case does, in particular materializing a strong reference to the object we're in the middle of deallocating (via a weakref that hasn't been cleared). That seems to be the key point. Mike found the problem in 2.2.2, I believe in his real-life OpenGL code. That's why I'm keen to see it fixed for 2.2.3. I'll be in the office Thursday, BTW. Ah, here, I'll attach a simpler program that has the same kind of problem (temp2.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-28 18:16 Message: Logged In: YES user_id=6380 Tim, let's look at this when you're back in the office. My head spins from just reading the analysis below. Note that this is a 2.2 and 2.3 bug. I don't necessarily want to hold up the 2.2.3 release until this is fixed, unless we have a quick breakthrough. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 00:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Thu May 29 01:01:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 17:01:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-744841 ] Python-Profiler bug: Bad call Message-ID: <E19LAqy-0006kk-00@sc8-sf-web2.sourceforge.net> Bugs item #744841, was opened at 2003-05-28 07:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744841&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: Python-Profiler bug: Bad call Initial Comment: There is a timing problem between the call of "call_trace(profile_func,...,'return',...)" and "reset_exc_info" in Pythons main interpreter loop. The main loop first calls "call_trace" (at the end of function execution). With the standard "profile.Profile" profiler this leads to a pop of the current frame from the profiler stack while the current frame is still on the interpreter stack. Then "reset_exc_info" is called. When this call releases an instance with a destructor ("__del__" method), the "call_trace(profile_func,...'call',...)" for the destructor observes the inconsistency between the profiler and the interpreter stack and raises a "Bad call" exception. This exception disables profiling effectively. However, the exception is later ignored (as we are in a destructor) and program execution continues. When the profiling is later finished, all time after the exception is accounted for the last function, that was on top of the profiler stack when profiling was disabled. This can be extremely confusing. The attached script reproduces the problem. Run it through the Python interpreter. When you see an "Exception Bad call ... ignored", the interpreter has the described problem. We observed the problem in Python 2.1.3 (on Linux, Solaris and Windows). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 20:01 Message: Logged In: YES user_id=33168 The good news is that this has been fixed in Python 2.2.x and beyond. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744841&group_id=5470 From noreply@sourceforge.net Thu May 29 01:18:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 17:18:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-745055 ] Memory leak in _tkinter.c/Tkapp_SplitList() Message-ID: <E19LB7R-0007H1-00@sc8-sf-web2.sourceforge.net> Bugs item #745055, was opened at 2003-05-28 13:55 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 Category: Tkinter >Group: Python 2.2.2 >Status: Open >Resolution: Fixed Priority: 5 Submitted By: Toni Leppäkorpi (leppako) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory leak in _tkinter.c/Tkapp_SplitList() Initial Comment: Splitlist() function leaks any string given to it as a parameter. This code should reproduce the problem: import Tkinter b = Tkinter.Button(text='Leak', command=lambda:b.tk.splitlist('1 2 {3 4} 5 '*10000)) b.pack() b.mainloop() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 20:18 Message: Logged In: YES user_id=33168 Checked in as Modules/_tkinter.c 1.160. Assigned to Barry to see if he wants it backported to 2.2.3. Otherwise, this should be backported to 2.2.4. ---------------------------------------------------------------------- Comment By: Toni Leppäkorpi (leppako) Date: 2003-05-28 17:47 Message: Logged In: YES user_id=788774 Good work nnorwitz. Problem solved. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 14:34 Message: Logged In: YES user_id=33168 Funny, I thought I had posted a patch about this. Could you test the attached patch which is against the CVS version? It shouldn't be hard to apply to 2.2.2/2.2.3 either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 From noreply@sourceforge.net Thu May 29 02:16:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 18:16:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19LC28-0000dV-00@sc8-sf-web2.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-28 21:16 Message: Logged In: YES user_id=34901 To give timeline: This is from real-life code (PyOpenGL's OpenGLContext demo/teaching module). It's currently about to go beta, with a release date target of end-of-summer. I've worked around the problem for the most common case w/in the system (exiting from the VRML browser), but that work-around's not usable for end-user long-running projects until the users can deallocate the scenegraph to load another (i.e. go from world to world within a single run of the application). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 19:26 Message: Logged In: YES user_id=31435 That's cool. The analysis is much easier to follow if you run Neal's little program, which crashes right away in a debug build. Then the analysis just follows the call stack, and it's instantly obvious (if you know to look for it <wink>) that we're trying to deallocate a single object twice. One thing subtype_delloc does that instance_dealloc doesn't is clear the instance dict before clearing the weakrefs. Clearing the instance dict can end up executing anything, and in this case does, in particular materializing a strong reference to the object we're in the middle of deallocating (via a weakref that hasn't been cleared). That seems to be the key point. Mike found the problem in 2.2.2, I believe in his real-life OpenGL code. That's why I'm keen to see it fixed for 2.2.3. I'll be in the office Thursday, BTW. Ah, here, I'll attach a simpler program that has the same kind of problem (temp2.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-28 18:16 Message: Logged In: YES user_id=6380 Tim, let's look at this when you're back in the office. My head spins from just reading the analysis below. Note that this is a 2.2 and 2.3 bug. I don't necessarily want to hold up the 2.2.3 release until this is fixed, unless we have a quick breakthrough. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 00:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Thu May 29 02:20:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 18:20:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-683061 ] gzip module cannot write large files Message-ID: <E19LC62-00043d-00@sc8-sf-web1.sourceforge.net> Bugs item #683061, was opened at 2003-02-08 11:52 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683061&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: gzip module cannot write large files Initial Comment: Something like this: import gzip fin = open("/dev/urandom", "rb") fout = gzip.GzipFile("out", "wb") for i in range(4500): fout.write(fin.read(1024*1024)) fout.close() will result in an error like: Exception 'long int too large to convert to int' raised of class 'exceptions.OverflowError': ... File "/usr/local/lib/python2.2/gzip.py", line 253, in close write32(self.fileobj, self.size) File "/usr/local/lib/python2.2/gzip.py", line 19, in write32 output.write(struct.pack("<l", value)) Tested in python 2.2.1 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-28 18:20 Message: Logged In: YES user_id=357491 >From what I can gather from cvs log this was not backported. Should it be? ---------------------------------------------------------------------- Comment By: Steven Taschuk (staschuk) Date: 2003-03-30 10:42 Message: Logged In: YES user_id=666873 Current CVS has a fix for this, as of revision 1.37 (part of 2.3a1). See patch 618135: http://www.python.org/sf/618135. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683061&group_id=5470 From noreply@sourceforge.net Thu May 29 02:33:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 18:33:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-693255 ] 2.3a2 site.py non-existing dirs Message-ID: <E19LCIT-00017k-00@sc8-sf-web2.sourceforge.net> Bugs item #693255, was opened at 2003-02-25 14:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: James P Rutledge (jrut) Assigned to: Just van Rossum (jvr) Summary: 2.3a2 site.py non-existing dirs Initial Comment: In Python 2.3a2 the site.py leaves non-existing directories in sys.path. On my Debian Linux system, using Python 2.3a2, the sys.path, after site.py is executed during interpreter initialization, includes the entry /usr/local/lib/python23.zip although no such directory currently exists on my system. The module documentation contained in site.py does state "Non-existing directories (or non-directories) are never added to sys.path" ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-28 18:33 Message: Logged In: YES user_id=357491 I take it the docs are what needs to change and not site.py? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-26 00:43 Message: Logged In: YES user_id=92689 The docs are indeed wrong. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 19:08 Message: Logged In: YES user_id=33168 Just, does the doc still need to be updated? ---------------------------------------------------------------------- Comment By: James P Rutledge (jrut) Date: 2003-02-25 18:56 Message: Logged In: YES user_id=720847 Additional info -- the site.py used in Python 2.2.2 explicitly removes non-existing and non-directory files from sys.path. The Python 2.3 site.py does not have that feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470 From noreply@sourceforge.net Thu May 29 02:50:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 18:50:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-697985 ] Move gmtime function from calendar to time module Message-ID: <E19LCYq-0002yW-00@sc8-sf-web3.sourceforge.net> Bugs item #697985, was opened at 2003-03-05 05:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Move gmtime function from calendar to time module Initial Comment: The gmtime function in the calendar module would be much more logical to have in the time module, since it manipulates tm tuples and unix timestamps, which the other functions in time do, but no other functions in calendar. Related to bug #697983 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-28 18:50 Message: Logged In: YES user_id=357491 OK, assuming the OP meant calendar.timegm , doesn't time.mktime provide the same functionality? Or is the desire to have it because it specifies the epoch as 1970-01-01? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-22 21:47 Message: Logged In: YES user_id=31435 I expect the OP meant the calendar.timegm() function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 14:46 Message: Logged In: YES user_id=33168 The gmtime function is in time, not calendar. Did you mean the opposite that you believe gmtime should be in calendar? gmtime comes from the C version which is the purpose of time, to expose C functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 From noreply@sourceforge.net Thu May 29 03:19:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 19:19:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-719367 ] string exceptions are deprecated Message-ID: <E19LD0p-0002RL-00@sc8-sf-web2.sourceforge.net> Bugs item #719367, was opened at 2003-04-10 19:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719367&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: string exceptions are deprecated Initial Comment: The deprecation (or at least pending deprecation) of string exceptions should be mentioned in the doc. There is no mention in ref 4.2: Doc/ref/ref4.tex. I'm not sure if the references to using strings should be removed or left in with a note/warning that string exceptions are deprecated and should be removed. I'll make the fix. Just let me know how to proceed. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 22:19 Message: Logged In: YES user_id=33168 Ok, I've removed all the references I found. Hope it looks good. Checked in as: * api/exceptions.tex: 1.15 * doc/doc.tex: 1.72 * lib/libexcs.tex: 1.52 * lib/libsys.tex: 1.64 * ref/ref4.tex: 1.36 * ref/ref6.tex: 1.65 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-04-10 22:51 Message: Logged In: YES user_id=3066 I'll suggest this approach: Remove all mention of string exceptions from the main text, and then add a child subsection (or whatever) or a "notice"** that describes string exceptions and their deprecated status. The C API reference already discusses the deprecation, but that could stand to be updated to mention the PendingDeprecationWarning. When your changes are ready, commit them to CVS; it's easier for me to look at them once their in. And I'm sure you'll do reasonable things. ;-) ** "notice" is a LaTeX environment in the Python styles: \begin{notice} text goes here \end{notice} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719367&group_id=5470 From noreply@sourceforge.net Thu May 29 03:59:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 19:59:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-697985 ] Move gmtime function from calendar to time module Message-ID: <E19LDdx-000774-00@sc8-sf-web1.sourceforge.net> Bugs item #697985, was opened at 2003-03-05 08:40 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Move gmtime function from calendar to time module Initial Comment: The gmtime function in the calendar module would be much more logical to have in the time module, since it manipulates tm tuples and unix timestamps, which the other functions in time do, but no other functions in calendar. Related to bug #697983 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-28 22:59 Message: Logged In: YES user_id=31435 mktime() interprets its argument as local time; timegm() as UTC. Generally speaking, time.mktime(time.localtime()) returns int(time.time()), and so does calendar.timegm(time.gmtime()) The OP appears to be right that the time module doesn't have an "inverse" for time.gmtime() in this sense. Then again, the time functions inherited from C are generally a twisted thicket. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-28 21:50 Message: Logged In: YES user_id=357491 OK, assuming the OP meant calendar.timegm , doesn't time.mktime provide the same functionality? Or is the desire to have it because it specifies the epoch as 1970-01-01? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 00:47 Message: Logged In: YES user_id=31435 I expect the OP meant the calendar.timegm() function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:46 Message: Logged In: YES user_id=33168 The gmtime function is in time, not calendar. Did you mean the opposite that you believe gmtime should be in calendar? gmtime comes from the C version which is the purpose of time, to expose C functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 From noreply@sourceforge.net Thu May 29 04:46:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 28 May 2003 20:46:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-745320 ] threads broke on FreeBSD current Message-ID: <E19LEMx-0003LA-00@sc8-sf-web4.sourceforge.net> Bugs item #745320, was opened at 2003-05-29 03:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745320&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Till Plewe (tpx) Assigned to: Nobody/Anonymous (nobody) Summary: threads broke on FreeBSD current Initial Comment: default configuration builts with the snapshot taken at 05-24-230001 but not with the snapshot from 05-26-230001 (--without-threads builts) I get the following compiler complaint when trying to build python_2003-05-26-230001: c++ -Wl,--export-dynamic -o python Modules/python.o libpython2.3.a -lutil - lm libpython2.3.a(posixmodule.o): In function `posix_tmpnam': Modules/posixmodule.c:5785: warning: tmpnam() possibly used unsafely; consider u sing mkstemp() libpython2.3.a(posixmodule.o): In function `posix_tempnam': Modules/posixmodule.c:5738: warning: tempnam() possibly used unsafely; consider using mkstemp() libpython2.3.a(thread.o): In function `PyThread_start_new_thread': Python/thread_pthread.h:217: undefined reference to `pthread_create' Python/thread_pthread.h:253: undefined reference to `pthread_detach' *** Error code 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745320&group_id=5470 From noreply@sourceforge.net Thu May 29 10:45:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 02:45:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-745424 ] Valgrind reports lots of problems Message-ID: <E19LJyd-0003cU-00@sc8-sf-web1.sourceforge.net> Bugs item #745424, was opened at 2003-05-29 09: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=745424&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stefane Fermigier (fermigier) Assigned to: Nobody/Anonymous (nobody) Summary: Valgrind reports lots of problems Initial Comment: Running valgrind (1.9.5) on Python CVS for 2003/05/29 on Mandrake cooker gives *lots* of errors: ==20937== ERROR SUMMARY: 1331 errors from 71 contexts (suppressed: 3 from 1) ==20937== malloc/free: in use at exit: 696167 bytes in 239 blocks. ==20937== malloc/free: 2822 allocs, 2583 frees, 1776937 bytes allocated. ==20937== For a detailed leak analysis, rerun with: --leak-check=yes ==20937== For counts of detected errors, rerun with: -v I´m not familiar enough with Python internals to tell if it´s a Python bug, a Valgrind bug or a problem with the distro. Running Valgrind on stock Mandrake Python (2.2.2) gives also some errors, though much less: fermigier@fermigier python/dist/src $ valgrind python < /dev/null ==20964== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==20964== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==20964== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==20964== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==20964== Estimated CPU clock rate is 2040 MHz ==20964== For more details, rerun with: -v ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x400087A6: elf_dynamic_do_rel.7 (do-rel.h:65) ==20964== by 0x40008EC8: _dl_relocate_object_internal (dl-reloc.c:217) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x400087AA: elf_dynamic_do_rel.7 (dl-machine.h:629) ==20964== by 0x40008EC8: _dl_relocate_object_internal (dl-reloc.c:217) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x40008FD3: _dl_relocate_object_internal (dl-machine.h:619) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== by 0x404F3FDE: _dl_open (in /lib/i686/libc-2.3.2.so) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x40009020: _dl_relocate_object_internal (do-rel.h:117) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== by 0x404F3FDE: _dl_open (in /lib/i686/libc-2.3.2.so) ==20964== ==20964== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 2 from 1) ==20964== malloc/free: in use at exit: 54679 bytes in 550 blocks. ==20964== malloc/free: 9626 allocs, 9076 frees, 993870 bytes allocated. ==20964== For a detailed leak analysis, rerun with: --leak-check=yes ==20964== For counts of detected errors, rerun with: -v ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745424&group_id=5470 From noreply@sourceforge.net Thu May 29 11:34:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 03:34:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-745424 ] Valgrind reports lots of problems Message-ID: <E19LKkF-0005Rd-00@sc8-sf-web1.sourceforge.net> Bugs item #745424, was opened at 2003-05-29 09:45 Message generated for change (Comment added) made by fermigier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745424&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stefane Fermigier (fermigier) Assigned to: Nobody/Anonymous (nobody) Summary: Valgrind reports lots of problems Initial Comment: Running valgrind (1.9.5) on Python CVS for 2003/05/29 on Mandrake cooker gives *lots* of errors: ==20937== ERROR SUMMARY: 1331 errors from 71 contexts (suppressed: 3 from 1) ==20937== malloc/free: in use at exit: 696167 bytes in 239 blocks. ==20937== malloc/free: 2822 allocs, 2583 frees, 1776937 bytes allocated. ==20937== For a detailed leak analysis, rerun with: --leak-check=yes ==20937== For counts of detected errors, rerun with: -v I´m not familiar enough with Python internals to tell if it´s a Python bug, a Valgrind bug or a problem with the distro. Running Valgrind on stock Mandrake Python (2.2.2) gives also some errors, though much less: fermigier@fermigier python/dist/src $ valgrind python < /dev/null ==20964== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==20964== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==20964== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==20964== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==20964== Estimated CPU clock rate is 2040 MHz ==20964== For more details, rerun with: -v ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x400087A6: elf_dynamic_do_rel.7 (do-rel.h:65) ==20964== by 0x40008EC8: _dl_relocate_object_internal (dl-reloc.c:217) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x400087AA: elf_dynamic_do_rel.7 (dl-machine.h:629) ==20964== by 0x40008EC8: _dl_relocate_object_internal (dl-reloc.c:217) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x40008FD3: _dl_relocate_object_internal (dl-machine.h:619) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== by 0x404F3FDE: _dl_open (in /lib/i686/libc-2.3.2.so) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x40009020: _dl_relocate_object_internal (do-rel.h:117) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== by 0x404F3FDE: _dl_open (in /lib/i686/libc-2.3.2.so) ==20964== ==20964== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 2 from 1) ==20964== malloc/free: in use at exit: 54679 bytes in 550 blocks. ==20964== malloc/free: 9626 allocs, 9076 frees, 993870 bytes allocated. ==20964== For a detailed leak analysis, rerun with: --leak-check=yes ==20964== For counts of detected errors, rerun with: -v ---------------------------------------------------------------------- >Comment By: Stefane Fermigier (fermigier) Date: 2003-05-29 10:34 Message: Logged In: YES user_id=43688 BTW, tcl, perl and ruby doesn´t show any errors or warnings in the same setup: fermigier@fermigier ~ $ valgrind ruby ==21283== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==21283== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==21283== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==21283== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==21283== Estimated CPU clock rate is 2020 MHz ==21283== For more details, rerun with: -v ==21283== ==21283== ==21283== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==21283== malloc/free: in use at exit: 320976 bytes in 6392 blocks. ==21283== malloc/free: 6652 allocs, 260 frees, 323272 bytes allocated. ==21283== For a detailed leak analysis, rerun with: --leak-check=yes ==21283== For counts of detected errors, rerun with: -v fermigier@fermigier ~ $ valgrind perl ==21284== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==21284== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==21284== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==21284== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==21284== Estimated CPU clock rate is 2019 MHz ==21284== For more details, rerun with: -v ==21284== ==21284== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup handlers are ignored) ==21284== ==21284== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) ==21284== malloc/free: in use at exit: 218136 bytes in 668 blocks. ==21284== malloc/free: 879 allocs, 211 frees, 236806 bytes allocated. ==21284== For a detailed leak analysis, rerun with: --leak-check=yes ==21284== For counts of detected errors, rerun with: -v fermigier@fermigier ~ $ valgrind tclsh < /dev/null ==21359== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==21359== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==21359== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==21359== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==21359== Estimated CPU clock rate is 2032 MHz ==21359== For more details, rerun with: -v ==21359== ==21359== ==21359== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==21359== malloc/free: in use at exit: 47453 bytes in 608 blocks. ==21359== malloc/free: 1420 allocs, 812 frees, 184123 bytes allocated. ==21359== For a detailed leak analysis, rerun with: --leak-check=yes ==21359== For counts of detected errors, rerun with: -v ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745424&group_id=5470 From noreply@sourceforge.net Thu May 29 13:08:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 05:08:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-745478 ] Buglet in email/Generator.py (2.2.3c1!) Message-ID: <E19LMDJ-0005kE-00@sc8-sf-web2.sourceforge.net> Bugs item #745478, was opened at 2003-05-29 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=745478&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Buglet in email/Generator.py (2.2.3c1!) Initial Comment: Hi, there seems to be a bug in the "email" package, file "Generator.py". At line 362, a random digit string is needed. This is done like this: dp = locale.localeconv().get('decimal_point') r = repr(random.random()).split(dp)[1] The problem is that repr() doesn't use the locale, so when the decimal_point is not equal to ".", split() returns only one entry and the [1] index fails. Suggested fix: either use: r = repr(random.random())[1:] or: r = repr(random.randint(0, sys.maxint-1)) The same problem is in 2.3b1. Geert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 From noreply@sourceforge.net Thu May 29 14:04:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 06:04:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-745478 ] Buglet in email/Generator.py (2.2.3c1!) Message-ID: <E19LN4h-0006KK-00@sc8-sf-web4.sourceforge.net> Bugs item #745478, was opened at 2003-05-29 08:08 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None >Priority: 9 Submitted By: Geert Jansen (geertj) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Buglet in email/Generator.py (2.2.3c1!) Initial Comment: Hi, there seems to be a bug in the "email" package, file "Generator.py". At line 362, a random digit string is needed. This is done like this: dp = locale.localeconv().get('decimal_point') r = repr(random.random()).split(dp)[1] The problem is that repr() doesn't use the locale, so when the decimal_point is not equal to ".", split() returns only one entry and the [1] index fails. Suggested fix: either use: r = repr(random.random())[1:] or: r = repr(random.randint(0, sys.maxint-1)) The same problem is in 2.3b1. Geert ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 09:04 Message: Logged In: YES user_id=12800 Cranking priority to 9 so this has to get fixed before 2.2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 From noreply@sourceforge.net Thu May 29 14:06:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 06:06:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-742860 ] WeakKeyDictionary __delitem__ uses iterkeys Message-ID: <E19LN6o-0006Q7-00@sc8-sf-web4.sourceforge.net> Bugs item #742860, was opened at 2003-05-24 16:24 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: WeakKeyDictionary __delitem__ uses iterkeys Initial Comment: iterkeys will raise a RuntimeError if the size of the dictionary changes during iteration. Deleting items from the dictionary may cause cascade deletions which will change the dictionary size. Possible solutions: Use keys instead of iterkeys: line 155 of weakref.py: for ref in self.data.keys(): Document the possibility that __delitem__ will raise RuntimeErrors (not a preferable solution). Note that there is also a potential race condition in the __delitem__ method, where the key is del'd from the data dictionary without a try: except: to catch cases where the key is deleted between the time the key is retrieved and the time the deletion occurs (which is more likely if keys is used, but could still happen with iterkeys). Same problem is seen in both 2.2.2 and 2.2.3 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 09:06 Message: Logged In: YES user_id=12800 With Fred's approval, we backported this to 2.2.3 ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-27 13:43 Message: Logged In: YES user_id=34901 Can't test 2.3 CVS just now (don't want to mess up the works while I'm debugging a wxPython bug). The one-liner: def __delitem__(self, key): del self.data[ref(key)] does appear to work under Python 2.2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 21:47 Message: Logged In: YES user_id=31435 Mike, can you try current CVS Python (2.3)? Fred won't be back for days, so I can't quiz him. I implemented the one- liner __delitem__, which is much faster, can't raise RuntimeError, and should be better behaved in all respects in the face of threads and/or comparison functions that mutate the dict as a side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 21:30 Message: Logged In: YES user_id=31435 Ah, threads. OK, but if two threads both try to delete the same key, then one of them *should* see a KeyError -- same as for a regular dict. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-24 20:58 Message: Logged In: YES user_id=34901 Re: race condition. Thread 1 calls del d[x] and then thread 2 calls del d[x]. Both have strong refs to the key, so the weakrefs don't die, both get the list of keys (weakrefs) to scan before either deletes a key, both then try to delete the item from the data dictionary. That is: t1: del d[x] t2: del d[x] t1: gets keys() t2: gets keys() t1: finds key in keys, does del data[ref] t2: finds key in keys (even though it's no longer in the dictionary), tries to do del data[ref], raises KeyError because t1 has already removed the weakref key from the data dictionary. I may be wrong, of course. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 20:36 Message: Logged In: YES user_id=31435 In staring at the code, I'm baffled as to why __delitem__ iterates over the keys at all. Why isn't the implementation the one-liner del self.data[ref(key)] ? That's basically what __contains__, has_key() and __getitem__ get away with. Two refs to the same object have the same hash codes and compare equal, so I'm having a hard time seeing why that isn't good enough for __delitem__ too. Mike, I didn't understand your point about the race condition. The object passed to __delitem__ as the key has a strong reference to it merely by virtue of having been passed to __delitem__, so it can't go away until (at earliest) __delitem__ returns (and so drops its strong reference to key). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 16:50 Message: Logged In: YES user_id=31435 Assigned to Fred (the original author, IIRC), and boosted priority a notch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742860&group_id=5470 From noreply@sourceforge.net Thu May 29 15:35:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 07:35:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19LOVO-0003ws-00@sc8-sf-web2.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-29 10:35 Message: Logged In: YES user_id=6380 Thanks to Tim for the analysis, to Neal for the simplified test, and to Mike for the bug report! The fix was actually simple: clear the weak ref list *before* calling __del__ or clearing __dict__. This is the same order as used by classic classes, so can't be wrong. Applied to 2.2.3 branch and 2.3 trunk, with test case. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-28 21:16 Message: Logged In: YES user_id=34901 To give timeline: This is from real-life code (PyOpenGL's OpenGLContext demo/teaching module). It's currently about to go beta, with a release date target of end-of-summer. I've worked around the problem for the most common case w/in the system (exiting from the VRML browser), but that work-around's not usable for end-user long-running projects until the users can deallocate the scenegraph to load another (i.e. go from world to world within a single run of the application). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 19:26 Message: Logged In: YES user_id=31435 That's cool. The analysis is much easier to follow if you run Neal's little program, which crashes right away in a debug build. Then the analysis just follows the call stack, and it's instantly obvious (if you know to look for it <wink>) that we're trying to deallocate a single object twice. One thing subtype_delloc does that instance_dealloc doesn't is clear the instance dict before clearing the weakrefs. Clearing the instance dict can end up executing anything, and in this case does, in particular materializing a strong reference to the object we're in the middle of deallocating (via a weakref that hasn't been cleared). That seems to be the key point. Mike found the problem in 2.2.2, I believe in his real-life OpenGL code. That's why I'm keen to see it fixed for 2.2.3. I'll be in the office Thursday, BTW. Ah, here, I'll attach a simpler program that has the same kind of problem (temp2.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-28 18:16 Message: Logged In: YES user_id=6380 Tim, let's look at this when you're back in the office. My head spins from just reading the analysis below. Note that this is a 2.2 and 2.3 bug. I don't necessarily want to hold up the 2.2.3 release until this is fixed, unless we have a quick breakthrough. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 00:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Thu May 29 15:53:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 07:53:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19LOmW-0004ss-00@sc8-sf-web2.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-05-29 10:53 Message: Logged In: YES user_id=31435 Just changed Resolution to Fixed. Thanks everyone! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-29 10:35 Message: Logged In: YES user_id=6380 Thanks to Tim for the analysis, to Neal for the simplified test, and to Mike for the bug report! The fix was actually simple: clear the weak ref list *before* calling __del__ or clearing __dict__. This is the same order as used by classic classes, so can't be wrong. Applied to 2.2.3 branch and 2.3 trunk, with test case. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-28 21:16 Message: Logged In: YES user_id=34901 To give timeline: This is from real-life code (PyOpenGL's OpenGLContext demo/teaching module). It's currently about to go beta, with a release date target of end-of-summer. I've worked around the problem for the most common case w/in the system (exiting from the VRML browser), but that work-around's not usable for end-user long-running projects until the users can deallocate the scenegraph to load another (i.e. go from world to world within a single run of the application). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 19:26 Message: Logged In: YES user_id=31435 That's cool. The analysis is much easier to follow if you run Neal's little program, which crashes right away in a debug build. Then the analysis just follows the call stack, and it's instantly obvious (if you know to look for it <wink>) that we're trying to deallocate a single object twice. One thing subtype_delloc does that instance_dealloc doesn't is clear the instance dict before clearing the weakrefs. Clearing the instance dict can end up executing anything, and in this case does, in particular materializing a strong reference to the object we're in the middle of deallocating (via a weakref that hasn't been cleared). That seems to be the key point. Mike found the problem in 2.2.2, I believe in his real-life OpenGL code. That's why I'm keen to see it fixed for 2.2.3. I'll be in the office Thursday, BTW. Ah, here, I'll attach a simpler program that has the same kind of problem (temp2.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-28 18:16 Message: Logged In: YES user_id=6380 Tim, let's look at this when you're back in the office. My head spins from just reading the analysis below. Note that this is a 2.2 and 2.3 bug. I don't necessarily want to hold up the 2.2.3 release until this is fixed, unless we have a quick breakthrough. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 00:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Thu May 29 16:14:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 08:14:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-736892 ] forcing function to act like an unbound method dumps core Message-ID: <E19LP7I-0004PK-00@sc8-sf-web4.sourceforge.net> Bugs item #736892, was opened at 2003-05-13 03:57 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Paul Du Bois (df-dubois) Assigned to: Barry A. Warsaw (bwarsaw) Summary: forcing function to act like an unbound method dumps core Initial Comment: Using ActivePython, v2.2.2 I was reading PEP252 and trying stupid things, like this: k [ 0:51] 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. >>> def func(): pass ... >>> f = func.__get__() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: function takes at least 1 argument (0 given) >>> f = func.__get__(None) >>> f() # This gives a reasonable result Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unbound method func() must be called with ? instance as first argument (got nothing instead) >>> f(1) # This crashes accessing a null pointer ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 11:14 Message: Logged In: YES user_id=12800 Fixed by backporting typeobject.c 2.206 patch. I also added a simple test. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-23 00:38 Message: Logged In: YES user_id=12800 Yes, let's try to get this fix into 2.2.3 final. I'll look at it if nobody beats me to it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:13 Message: Logged In: YES user_id=33168 Bumping priority. Barry, do you want to handle this for 2.2.3? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-05-13 14:27 Message: Logged In: YES user_id=11375 It seems to be fixed in 2.3CVS: >>> f = func.__get__(None) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: __get__(None, None) is invalid The fix needs to be backported to the 2.2 branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736892&group_id=5470 From noreply@sourceforge.net Thu May 29 17:22:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 09:22:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-697985 ] Move gmtime function from calendar to time module Message-ID: <E19LQAl-0004wo-00@sc8-sf-web1.sourceforge.net> Bugs item #697985, was opened at 2003-03-05 05:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Move gmtime function from calendar to time module Initial Comment: The gmtime function in the calendar module would be much more logical to have in the time module, since it manipulates tm tuples and unix timestamps, which the other functions in time do, but no other functions in calendar. Related to bug #697983 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-05-29 09:22 Message: Logged In: YES user_id=357491 Well then, is there any desire to bother to make this happen? Or is this just a "I hope someone likes this idea enough to implement it" instance in which case this should probably be made an RFE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 19:59 Message: Logged In: YES user_id=31435 mktime() interprets its argument as local time; timegm() as UTC. Generally speaking, time.mktime(time.localtime()) returns int(time.time()), and so does calendar.timegm(time.gmtime()) The OP appears to be right that the time module doesn't have an "inverse" for time.gmtime() in this sense. Then again, the time functions inherited from C are generally a twisted thicket. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-28 18:50 Message: Logged In: YES user_id=357491 OK, assuming the OP meant calendar.timegm , doesn't time.mktime provide the same functionality? Or is the desire to have it because it specifies the epoch as 1970-01-01? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-22 21:47 Message: Logged In: YES user_id=31435 I expect the OP meant the calendar.timegm() function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 14:46 Message: Logged In: YES user_id=33168 The gmtime function is in time, not calendar. Did you mean the opposite that you believe gmtime should be in calendar? gmtime comes from the C version which is the purpose of time, to expose C functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 From noreply@sourceforge.net Thu May 29 18:52:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 10:52:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-745424 ] Valgrind reports lots of problems Message-ID: <E19LRZs-0003in-00@sc8-sf-web4.sourceforge.net> Bugs item #745424, was opened at 2003-05-29 09:45 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745424&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Stefane Fermigier (fermigier) Assigned to: Nobody/Anonymous (nobody) Summary: Valgrind reports lots of problems Initial Comment: Running valgrind (1.9.5) on Python CVS for 2003/05/29 on Mandrake cooker gives *lots* of errors: ==20937== ERROR SUMMARY: 1331 errors from 71 contexts (suppressed: 3 from 1) ==20937== malloc/free: in use at exit: 696167 bytes in 239 blocks. ==20937== malloc/free: 2822 allocs, 2583 frees, 1776937 bytes allocated. ==20937== For a detailed leak analysis, rerun with: --leak-check=yes ==20937== For counts of detected errors, rerun with: -v I´m not familiar enough with Python internals to tell if it´s a Python bug, a Valgrind bug or a problem with the distro. Running Valgrind on stock Mandrake Python (2.2.2) gives also some errors, though much less: fermigier@fermigier python/dist/src $ valgrind python < /dev/null ==20964== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==20964== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==20964== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==20964== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==20964== Estimated CPU clock rate is 2040 MHz ==20964== For more details, rerun with: -v ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x400087A6: elf_dynamic_do_rel.7 (do-rel.h:65) ==20964== by 0x40008EC8: _dl_relocate_object_internal (dl-reloc.c:217) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x400087AA: elf_dynamic_do_rel.7 (dl-machine.h:629) ==20964== by 0x40008EC8: _dl_relocate_object_internal (dl-reloc.c:217) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x40008FD3: _dl_relocate_object_internal (dl-machine.h:619) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== by 0x404F3FDE: _dl_open (in /lib/i686/libc-2.3.2.so) ==20964== ==20964== Conditional jump or move depends on uninitialised value(s) ==20964== at 0x40009020: _dl_relocate_object_internal (do-rel.h:117) ==20964== by 0x404F48B4: (within /lib/i686/libc-2.3.2.so) ==20964== by 0x4000ADC7: _dl_catch_error_internal (dl-error.c:162) ==20964== by 0x404F3FDE: _dl_open (in /lib/i686/libc-2.3.2.so) ==20964== ==20964== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 2 from 1) ==20964== malloc/free: in use at exit: 54679 bytes in 550 blocks. ==20964== malloc/free: 9626 allocs, 9076 frees, 993870 bytes allocated. ==20964== For a detailed leak analysis, rerun with: --leak-check=yes ==20964== For counts of detected errors, rerun with: -v ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-05-29 17:52 Message: Logged In: YES user_id=31392 Sorry. A Valgrind report without some analysis of how it applies to Python isn't really helpful. If someone is going to dig into what these errors mean, they can probably run Valgrind. ---------------------------------------------------------------------- Comment By: Stefane Fermigier (fermigier) Date: 2003-05-29 10:34 Message: Logged In: YES user_id=43688 BTW, tcl, perl and ruby doesn´t show any errors or warnings in the same setup: fermigier@fermigier ~ $ valgrind ruby ==21283== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==21283== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==21283== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==21283== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==21283== Estimated CPU clock rate is 2020 MHz ==21283== For more details, rerun with: -v ==21283== ==21283== ==21283== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==21283== malloc/free: in use at exit: 320976 bytes in 6392 blocks. ==21283== malloc/free: 6652 allocs, 260 frees, 323272 bytes allocated. ==21283== For a detailed leak analysis, rerun with: --leak-check=yes ==21283== For counts of detected errors, rerun with: -v fermigier@fermigier ~ $ valgrind perl ==21284== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==21284== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==21284== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==21284== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==21284== Estimated CPU clock rate is 2019 MHz ==21284== For more details, rerun with: -v ==21284== ==21284== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup handlers are ignored) ==21284== ==21284== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) ==21284== malloc/free: in use at exit: 218136 bytes in 668 blocks. ==21284== malloc/free: 879 allocs, 211 frees, 236806 bytes allocated. ==21284== For a detailed leak analysis, rerun with: --leak-check=yes ==21284== For counts of detected errors, rerun with: -v fermigier@fermigier ~ $ valgrind tclsh < /dev/null ==21359== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==21359== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==21359== Using valgrind-1.9.5, a program instrumentation system for x86-linux. ==21359== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==21359== Estimated CPU clock rate is 2032 MHz ==21359== For more details, rerun with: -v ==21359== ==21359== ==21359== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==21359== malloc/free: in use at exit: 47453 bytes in 608 blocks. ==21359== malloc/free: 1420 allocs, 812 frees, 184123 bytes allocated. ==21359== For a detailed leak analysis, rerun with: --leak-check=yes ==21359== For counts of detected errors, rerun with: -v ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745424&group_id=5470 From noreply@sourceforge.net Thu May 29 19:43:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 11:43:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-745055 ] Memory leak in _tkinter.c/Tkapp_SplitList() Message-ID: <E19LSNE-0003PD-00@sc8-sf-web1.sourceforge.net> Bugs item #745055, was opened at 2003-05-28 13:55 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Toni Leppäkorpi (leppako) >Assigned to: Neal Norwitz (nnorwitz) Summary: Memory leak in _tkinter.c/Tkapp_SplitList() Initial Comment: Splitlist() function leaks any string given to it as a parameter. This code should reproduce the problem: import Tkinter b = Tkinter.Button(text='Leak', command=lambda:b.tk.splitlist('1 2 {3 4} 5 '*10000)) b.pack() b.mainloop() ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 14:43 Message: Logged In: YES user_id=12800 Neal, go ahead and back port it. Tim's checking new features into 2.2.3 on BDFL directive, so this one can't do much more harm <wink>. I still don't think we need another release candidate. There's always 2.2.4 next week. :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 20:18 Message: Logged In: YES user_id=33168 Checked in as Modules/_tkinter.c 1.160. Assigned to Barry to see if he wants it backported to 2.2.3. Otherwise, this should be backported to 2.2.4. ---------------------------------------------------------------------- Comment By: Toni Leppäkorpi (leppako) Date: 2003-05-28 17:47 Message: Logged In: YES user_id=788774 Good work nnorwitz. Problem solved. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 14:34 Message: Logged In: YES user_id=33168 Funny, I thought I had posted a patch about this. Could you test the attached patch which is against the CVS version? It shouldn't be hard to apply to 2.2.2/2.2.3 either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 From noreply@sourceforge.net Thu May 29 19:59:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 11:59:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-745055 ] Memory leak in _tkinter.c/Tkapp_SplitList() Message-ID: <E19LScT-00009j-00@sc8-sf-web2.sourceforge.net> Bugs item #745055, was opened at 2003-05-28 13:55 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 Category: Tkinter Group: Python 2.2.2 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Toni Leppäkorpi (leppako) Assigned to: Neal Norwitz (nnorwitz) Summary: Memory leak in _tkinter.c/Tkapp_SplitList() Initial Comment: Splitlist() function leaks any string given to it as a parameter. This code should reproduce the problem: import Tkinter b = Tkinter.Button(text='Leak', command=lambda:b.tk.splitlist('1 2 {3 4} 5 '*10000)) b.pack() b.mainloop() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-29 14:59 Message: Logged In: YES user_id=33168 :-) Checked in as: Modules/_tkinter.c 1.121.6.3 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 14:43 Message: Logged In: YES user_id=12800 Neal, go ahead and back port it. Tim's checking new features into 2.2.3 on BDFL directive, so this one can't do much more harm <wink>. I still don't think we need another release candidate. There's always 2.2.4 next week. :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 20:18 Message: Logged In: YES user_id=33168 Checked in as Modules/_tkinter.c 1.160. Assigned to Barry to see if he wants it backported to 2.2.3. Otherwise, this should be backported to 2.2.4. ---------------------------------------------------------------------- Comment By: Toni Leppäkorpi (leppako) Date: 2003-05-28 17:47 Message: Logged In: YES user_id=788774 Good work nnorwitz. Problem solved. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-28 14:34 Message: Logged In: YES user_id=33168 Funny, I thought I had posted a patch about this. Could you test the attached patch which is against the CVS version? It shouldn't be hard to apply to 2.2.2/2.2.3 either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745055&group_id=5470 From noreply@sourceforge.net Thu May 29 20:20:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 12:20:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-693255 ] 2.3a2 site.py non-existing dirs Message-ID: <E19LSxI-000130-00@sc8-sf-web2.sourceforge.net> Bugs item #693255, was opened at 2003-02-25 15:44 Message generated for change (Comment added) made by jrut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: James P Rutledge (jrut) Assigned to: Just van Rossum (jvr) Summary: 2.3a2 site.py non-existing dirs Initial Comment: In Python 2.3a2 the site.py leaves non-existing directories in sys.path. On my Debian Linux system, using Python 2.3a2, the sys.path, after site.py is executed during interpreter initialization, includes the entry /usr/local/lib/python23.zip although no such directory currently exists on my system. The module documentation contained in site.py does state "Non-existing directories (or non-directories) are never added to sys.path" ---------------------------------------------------------------------- >Comment By: James P Rutledge (jrut) Date: 2003-05-29 13:20 Message: Logged In: YES user_id=720847 I do not know what policy is desired for the condition of the path after executing site.py. I found the problem when I switched to try 2.3 and used an application I wrote which searches the path to obtain information about installed modules. During troubleshooting, the change in site.py from 2.2 to 2.3, to stop removing non-existent directories in the path, became evident as the reason for the application finding a non-existent directory in the path. The application was, of course, easily changed to skip non-existent directories. The question is whether removing of non-existent directories in the path _should_ be done by site.py ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-28 19:33 Message: Logged In: YES user_id=357491 I take it the docs are what needs to change and not site.py? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-26 01:43 Message: Logged In: YES user_id=92689 The docs are indeed wrong. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 20:08 Message: Logged In: YES user_id=33168 Just, does the doc still need to be updated? ---------------------------------------------------------------------- Comment By: James P Rutledge (jrut) Date: 2003-02-25 19:56 Message: Logged In: YES user_id=720847 Additional info -- the site.py used in Python 2.2.2 explicitly removes non-existing and non-directory files from sys.path. The Python 2.3 site.py does not have that feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470 From noreply@sourceforge.net Thu May 29 20:26:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 12:26:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-745478 ] Buglet in email/Generator.py (2.2.3c1!) Message-ID: <E19LT2a-0002T7-00@sc8-sf-web3.sourceforge.net> Bugs item #745478, was opened at 2003-05-29 08:08 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 9 Submitted By: Geert Jansen (geertj) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Buglet in email/Generator.py (2.2.3c1!) Initial Comment: Hi, there seems to be a bug in the "email" package, file "Generator.py". At line 362, a random digit string is needed. This is done like this: dp = locale.localeconv().get('decimal_point') r = repr(random.random()).split(dp)[1] The problem is that repr() doesn't use the locale, so when the decimal_point is not equal to ".", split() returns only one entry and the [1] index fails. Suggested fix: either use: r = repr(random.random())[1:] or: r = repr(random.randint(0, sys.maxint-1)) The same problem is in 2.3b1. Geert ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 15:26 Message: Logged In: YES user_id=12800 Please try this patch. After applying, please run the full Python 2.2.3 test suite. If there are no regressions in your locale, then I might be willing to add it to 2.2.3 final. But the test makes me nervous. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 09:04 Message: Logged In: YES user_id=12800 Cranking priority to 9 so this has to get fixed before 2.2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 From noreply@sourceforge.net Thu May 29 20:34:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 12:34:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-745478 ] Buglet in email/Generator.py (2.2.3c1!) Message-ID: <E19LTAI-0002sf-00@sc8-sf-web3.sourceforge.net> Bugs item #745478, was opened at 2003-05-29 08:08 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Geert Jansen (geertj) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Buglet in email/Generator.py (2.2.3c1!) Initial Comment: Hi, there seems to be a bug in the "email" package, file "Generator.py". At line 362, a random digit string is needed. This is done like this: dp = locale.localeconv().get('decimal_point') r = repr(random.random()).split(dp)[1] The problem is that repr() doesn't use the locale, so when the decimal_point is not equal to ".", split() returns only one entry and the [1] index fails. Suggested fix: either use: r = repr(random.random())[1:] or: r = repr(random.randint(0, sys.maxint-1)) The same problem is in 2.3b1. Geert ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 15:34 Message: Logged In: YES user_id=12800 On further reflection w/ BDFL, we'll include the patch but not the test, since it's testing the old code which we're replacing anyway. ;) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 15:26 Message: Logged In: YES user_id=12800 Please try this patch. After applying, please run the full Python 2.2.3 test suite. If there are no regressions in your locale, then I might be willing to add it to 2.2.3 final. But the test makes me nervous. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 09:04 Message: Logged In: YES user_id=12800 Cranking priority to 9 so this has to get fixed before 2.2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 From noreply@sourceforge.net Thu May 29 20:55:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 12:55:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-734695 ] Function for creating/extracting CoreFoundation types Message-ID: <E19LTVB-00048h-00@sc8-sf-web3.sourceforge.net> Bugs item #734695, was opened at 2003-05-08 17:15 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 Category: Macintosh Group: Feature Request >Status: Closed Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Function for creating/extracting CoreFoundation types Initial Comment: pymactoolbox.h contains a number of functions for converting from CoreFoundation references to Python wrappers for those functions (e.g. CFTypeRefObj_New). Simularly there are functions for extracting the CoreFoundation reference from a wrapped Python object (e.g. CFTypeRefObj_Convert). It would be nice if CFTypeRefObj_New would automaticly create a more specialized Python wrapper if you pass it a CFArrayRef, this decreases the coupling between the python core and 3th party extension modules. Simularly CFTypeRefObj_Convert should "work" when passed a CFArrayRefObj. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-05-29 21:55 Message: Logged In: YES user_id=580910 The new functions seem to work just fine, and the implementation looks OK too. I think the current implementation is fine, automaticly converting only some types to/from their python equivalent would be confusing. Furthermore the current behaviour allows me to get as close as possible to 'toll-free bridging' , which means it should be possible to translate code examples that use this feature into Python without too many problems. Thanks for implementing this! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-27 23:43 Message: Logged In: YES user_id=45365 Implemented in CVS, but I have called the new generalized functions CFObj_New() and CFObj_Convert(). One issue is open to discussion: currently CFObj_New() expects a CFTypeRef object for which a wrapper is available. An alternative would be to use PyCF_CF2Python() otherwise (so CFNumber would get mapped to a Python int, etc). Similarly for CFObj_Convert(), which expects an object of one of the classes Carbon.CF implements. It could also fall back to using PyCF_Python2CF(). Let me know which solution is better. Also: the code is pretty much untested. Please test, and close this report when you're satisfied (and after answering the previous question). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 From noreply@sourceforge.net Thu May 29 21:47:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 13:47:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19LUJR-0005Qw-00@sc8-sf-web2.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 17:29 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-05-29 15:47 Message: Logged In: YES user_id=2772 Just one question: does the final test-case cover the original bug? I have a redhat 9 system with Python 2.2.2, and temp2.py runs just fine: $ python2 temp2.py <__main__.Oops object at 0x8162ecc> $ The Python version is: Python 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 I have not tried any other version of the test-case. I also didn't try a non-redhat version, so it's barely possible that some patch they apply affected this issue. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-29 09:53 Message: Logged In: YES user_id=31435 Just changed Resolution to Fixed. Thanks everyone! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-29 09:35 Message: Logged In: YES user_id=6380 Thanks to Tim for the analysis, to Neal for the simplified test, and to Mike for the bug report! The fix was actually simple: clear the weak ref list *before* calling __del__ or clearing __dict__. This is the same order as used by classic classes, so can't be wrong. Applied to 2.2.3 branch and 2.3 trunk, with test case. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-28 20:16 Message: Logged In: YES user_id=34901 To give timeline: This is from real-life code (PyOpenGL's OpenGLContext demo/teaching module). It's currently about to go beta, with a release date target of end-of-summer. I've worked around the problem for the most common case w/in the system (exiting from the VRML browser), but that work-around's not usable for end-user long-running projects until the users can deallocate the scenegraph to load another (i.e. go from world to world within a single run of the application). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 18:26 Message: Logged In: YES user_id=31435 That's cool. The analysis is much easier to follow if you run Neal's little program, which crashes right away in a debug build. Then the analysis just follows the call stack, and it's instantly obvious (if you know to look for it <wink>) that we're trying to deallocate a single object twice. One thing subtype_delloc does that instance_dealloc doesn't is clear the instance dict before clearing the weakrefs. Clearing the instance dict can end up executing anything, and in this case does, in particular materializing a strong reference to the object we're in the middle of deallocating (via a weakref that hasn't been cleared). That seems to be the key point. Mike found the problem in 2.2.2, I believe in his real-life OpenGL code. That's why I'm keen to see it fixed for 2.2.3. I'll be in the office Thursday, BTW. Ah, here, I'll attach a simpler program that has the same kind of problem (temp2.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-28 17:16 Message: Logged In: YES user_id=6380 Tim, let's look at this when you're back in the office. My head spins from just reading the analysis below. Note that this is a 2.2 and 2.3 bug. I don't necessarily want to hold up the 2.2.3 release until this is fixed, unless we have a quick breakthrough. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 23:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 21:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 18:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Thu May 29 21:54:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 13:54:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-745478 ] Buglet in email/Generator.py (2.2.3c1!) Message-ID: <E19LUPy-0007cO-00@sc8-sf-web1.sourceforge.net> Bugs item #745478, was opened at 2003-05-29 14:08 Message generated for change (Comment added) made by geertj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 9 Submitted By: Geert Jansen (geertj) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Buglet in email/Generator.py (2.2.3c1!) Initial Comment: Hi, there seems to be a bug in the "email" package, file "Generator.py". At line 362, a random digit string is needed. This is done like this: dp = locale.localeconv().get('decimal_point') r = repr(random.random()).split(dp)[1] The problem is that repr() doesn't use the locale, so when the decimal_point is not equal to ".", split() returns only one entry and the [1] index fails. Suggested fix: either use: r = repr(random.random())[1:] or: r = repr(random.randint(0, sys.maxint-1)) The same problem is in 2.3b1. Geert ---------------------------------------------------------------------- >Comment By: Geert Jansen (geertj) Date: 2003-05-29 22:54 Message: Logged In: YES user_id=537938 Thanks for the patch. I see you've already committed to CVS so I'm not sure if you still want me to run the test suite. To be sure I ran it anyway and there were no errors. Geert ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 21:34 Message: Logged In: YES user_id=12800 On further reflection w/ BDFL, we'll include the patch but not the test, since it's testing the old code which we're replacing anyway. ;) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 21:26 Message: Logged In: YES user_id=12800 Please try this patch. After applying, please run the full Python 2.2.3 test suite. If there are no regressions in your locale, then I might be willing to add it to 2.2.3 final. But the test makes me nervous. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 15:04 Message: Logged In: YES user_id=12800 Cranking priority to 9 so this has to get fixed before 2.2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 From noreply@sourceforge.net Thu May 29 21:55:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 13:55:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-734695 ] Function for creating/extracting CoreFoundation types Message-ID: <E19LUQQ-0005ns-00@sc8-sf-web2.sourceforge.net> Bugs item #734695, was opened at 2003-05-08 17:15 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 Category: Macintosh Group: Feature Request >Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Function for creating/extracting CoreFoundation types Initial Comment: pymactoolbox.h contains a number of functions for converting from CoreFoundation references to Python wrappers for those functions (e.g. CFTypeRefObj_New). Simularly there are functions for extracting the CoreFoundation reference from a wrapped Python object (e.g. CFTypeRefObj_Convert). It would be nice if CFTypeRefObj_New would automaticly create a more specialized Python wrapper if you pass it a CFArrayRef, this decreases the coupling between the python core and 3th party extension modules. Simularly CFTypeRefObj_Convert should "work" when passed a CFArrayRefObj. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-05-29 22:55 Message: Logged In: YES user_id=580910 My initial tests were a little too easy, now that I've completely rebuild PyObjC I see: ImportError: Module did not provide routine: Carbon.CF: CFObj_New Shouldn't there be code in _CFmodule.c to make sure that the mactoolboxglue can find the two new functions? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-05-29 21:55 Message: Logged In: YES user_id=580910 The new functions seem to work just fine, and the implementation looks OK too. I think the current implementation is fine, automaticly converting only some types to/from their python equivalent would be confusing. Furthermore the current behaviour allows me to get as close as possible to 'toll-free bridging' , which means it should be possible to translate code examples that use this feature into Python without too many problems. Thanks for implementing this! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-27 23:43 Message: Logged In: YES user_id=45365 Implemented in CVS, but I have called the new generalized functions CFObj_New() and CFObj_Convert(). One issue is open to discussion: currently CFObj_New() expects a CFTypeRef object for which a wrapper is available. An alternative would be to use PyCF_CF2Python() otherwise (so CFNumber would get mapped to a Python int, etc). Similarly for CFObj_Convert(), which expects an object of one of the classes Carbon.CF implements. It could also fall back to using PyCF_Python2CF(). Let me know which solution is better. Also: the code is pretty much untested. Please test, and close this report when you're satisfied (and after answering the previous question). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 From noreply@sourceforge.net Thu May 29 22:01:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 14:01:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-745478 ] Buglet in email/Generator.py (2.2.3c1!) Message-ID: <E19LUWp-0004Wb-00@sc8-sf-web4.sourceforge.net> Bugs item #745478, was opened at 2003-05-29 08:08 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 9 Submitted By: Geert Jansen (geertj) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Buglet in email/Generator.py (2.2.3c1!) Initial Comment: Hi, there seems to be a bug in the "email" package, file "Generator.py". At line 362, a random digit string is needed. This is done like this: dp = locale.localeconv().get('decimal_point') r = repr(random.random()).split(dp)[1] The problem is that repr() doesn't use the locale, so when the decimal_point is not equal to ".", split() returns only one entry and the [1] index fails. Suggested fix: either use: r = repr(random.random())[1:] or: r = repr(random.randint(0, sys.maxint-1)) The same problem is in 2.3b1. Geert ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 17:01 Message: Logged In: YES user_id=12800 thanks for the confirmation. this made it to 2.2.3 ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2003-05-29 16:54 Message: Logged In: YES user_id=537938 Thanks for the patch. I see you've already committed to CVS so I'm not sure if you still want me to run the test suite. To be sure I ran it anyway and there were no errors. Geert ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 15:34 Message: Logged In: YES user_id=12800 On further reflection w/ BDFL, we'll include the patch but not the test, since it's testing the old code which we're replacing anyway. ;) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 15:26 Message: Logged In: YES user_id=12800 Please try this patch. After applying, please run the full Python 2.2.3 test suite. If there are no regressions in your locale, then I might be willing to add it to 2.2.3 final. But the test makes me nervous. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-29 09:04 Message: Logged In: YES user_id=12800 Cranking priority to 9 so this has to get fixed before 2.2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745478&group_id=5470 From noreply@sourceforge.net Thu May 29 22:35:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 14:35:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19LV3k-0000rs-00@sc8-sf-web1.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-29 17:35 Message: Logged In: YES user_id=33168 2.3 works for me with the original, but didn't before. Redhat 9. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-05-29 16:47 Message: Logged In: YES user_id=2772 Just one question: does the final test-case cover the original bug? I have a redhat 9 system with Python 2.2.2, and temp2.py runs just fine: $ python2 temp2.py <__main__.Oops object at 0x8162ecc> $ The Python version is: Python 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 I have not tried any other version of the test-case. I also didn't try a non-redhat version, so it's barely possible that some patch they apply affected this issue. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-29 10:53 Message: Logged In: YES user_id=31435 Just changed Resolution to Fixed. Thanks everyone! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-29 10:35 Message: Logged In: YES user_id=6380 Thanks to Tim for the analysis, to Neal for the simplified test, and to Mike for the bug report! The fix was actually simple: clear the weak ref list *before* calling __del__ or clearing __dict__. This is the same order as used by classic classes, so can't be wrong. Applied to 2.2.3 branch and 2.3 trunk, with test case. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-28 21:16 Message: Logged In: YES user_id=34901 To give timeline: This is from real-life code (PyOpenGL's OpenGLContext demo/teaching module). It's currently about to go beta, with a release date target of end-of-summer. I've worked around the problem for the most common case w/in the system (exiting from the VRML browser), but that work-around's not usable for end-user long-running projects until the users can deallocate the scenegraph to load another (i.e. go from world to world within a single run of the application). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 19:26 Message: Logged In: YES user_id=31435 That's cool. The analysis is much easier to follow if you run Neal's little program, which crashes right away in a debug build. Then the analysis just follows the call stack, and it's instantly obvious (if you know to look for it <wink>) that we're trying to deallocate a single object twice. One thing subtype_delloc does that instance_dealloc doesn't is clear the instance dict before clearing the weakrefs. Clearing the instance dict can end up executing anything, and in this case does, in particular materializing a strong reference to the object we're in the middle of deallocating (via a weakref that hasn't been cleared). That seems to be the key point. Mike found the problem in 2.2.2, I believe in his real-life OpenGL code. That's why I'm keen to see it fixed for 2.2.3. I'll be in the office Thursday, BTW. Ah, here, I'll attach a simpler program that has the same kind of problem (temp2.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-28 18:16 Message: Logged In: YES user_id=6380 Tim, let's look at this when you're back in the office. My head spins from just reading the analysis below. Note that this is a 2.2 and 2.3 bug. I don't necessarily want to hold up the 2.2.3 release until this is fixed, unless we have a quick breakthrough. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 00:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Fri May 30 12:02:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 04:02:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-746012 ] PACKAGE_ in pyconfig.h Message-ID: <E19Lhek-0000Ji-00@sc8-sf-web3.sourceforge.net> Bugs item #746012, was opened at 2003-05-30 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=105470&aid=746012&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: PACKAGE_ in pyconfig.h Initial Comment: Is it intentional that in 2.3 pyconfig.h includes PACKAGE_* definitions? It causes lot of warnings when building modules (and maybe some other problems). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746012&group_id=5470 From noreply@sourceforge.net Fri May 30 13:10:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 05:10:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-746012 ] PACKAGE_* in pyconfig.h Message-ID: <E19Lii9-0003zX-00@sc8-sf-web2.sourceforge.net> Bugs item #746012, was opened at 2003-05-30 13:02 Message generated for change (Settings changed) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746012&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) >Summary: PACKAGE_* in pyconfig.h Initial Comment: Is it intentional that in 2.3 pyconfig.h includes PACKAGE_* definitions? It causes lot of warnings when building modules (and maybe some other problems). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746012&group_id=5470 From noreply@sourceforge.net Fri May 30 20:59:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 12:59:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-746304 ] TypeError raised when deepcopying built-in functions Message-ID: <E19Lq2h-0007z1-00@sc8-sf-web4.sourceforge.net> Bugs item #746304, was opened at 2003-05-30 22:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746304&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Oktay Safak (oktaysafak) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError raised when deepcopying built-in functions Initial Comment: >>> import copy >>> copy.deepcopy(max) Traceback (most recent call last): File "<pyshell#2>", line 1, in ? copy.deepcopy(max) File "C:\PYTHON23\lib\copy.py", line 205, in deepcopy y = _reconstruct(x, rv, 1, memo) File "C:\PYTHON23\lib\copy.py", line 336, in _reconstruct y = callable(*args) File "C:\PYTHON23\Lib\copy_reg.py", line 84, in __newobj__ return cls.__new__(cls, *args) TypeError: object.__new__(builtin_function_or_method) is not safe, use builtin_function_or_method.__new__() Steven Taschuk's guess is that all things pickleable should be copyable since copy uses the same protocol as pickle. (He is not sure though) He demonstrates this idea with the following example: >>> import pickle >>> pickle.loads(pickle.dumps(max)) <built-in function max> which succeeds unlike the first example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746304&group_id=5470 From noreply@sourceforge.net Fri May 30 23:01:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 15:01:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-746366 ] 2.2.3c1 install-sh out of date Message-ID: <E19Lrw5-0004HP-00@sc8-sf-web4.sourceforge.net> Bugs item #746366, was opened at 2003-05-30 22:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746366&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2.3c1 install-sh out of date Initial Comment: The install-sh shipped with Python 2.2.3c1 is out of date with respect to the canonical install-sh shipped with Automake. The Automake version has fixed a few portability bugs having to do with spaces in directory names, the unportable use of "[ ... -o ... ]", and the like. The simplest fix is to copy automake/lib/install-sh into Python. I'll also try to attach a patch below. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746366&group_id=5470 From noreply@sourceforge.net Fri May 30 23:07:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 30 May 2003 15:07:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-746366 ] 2.2.3c1 install-sh out of date Message-ID: <E19Ls1u-0004RQ-00@sc8-sf-web4.sourceforge.net> Bugs item #746366, was opened at 2003-05-30 18:01 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746366&group_id=5470 Category: Build >Group: Python 2.2.3 Status: Open >Resolution: Later Priority: 5 Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2.3c1 install-sh out of date Initial Comment: The install-sh shipped with Python 2.2.3c1 is out of date with respect to the canonical install-sh shipped with Automake. The Automake version has fixed a few portability bugs having to do with spaces in directory names, the unportable use of "[ ... -o ... ]", and the like. The simplest fix is to copy automake/lib/install-sh into Python. I'll also try to attach a patch below. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-30 18:07 Message: Logged In: YES user_id=12800 Sorry, its too late to fix this for Python 2.2.3. Setting resolution to Later for consideration in 2.2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746366&group_id=5470 From noreply@sourceforge.net Sat May 31 08:04:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 00:04:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-733667 ] kwargs handled incorrectly Message-ID: <E19M0Q2-0004iy-00@sc8-sf-web1.sourceforge.net> Bugs item #733667, was opened at 2003-05-07 01:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Andrew Dalke (dalke) Assigned to: Jeremy Hylton (jhylton) Summary: kwargs handled incorrectly Initial Comment: I'm using Python2.3 (first with a1 then tested with CVS version "Python 2.3b1+ (#7, May 6 2003, 23:41:12)" compiled a few minutes ago). There's a bug in how it handles an error condition with keyword arguments. Here's a reproducible Python 2.3b1+ (#7, May 6 2003, 23:41:12) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def add(a, b): ... print "add", repr(a), repr(b) ... return a + b ... >>> add(a=3) add 'a' 3 Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in add TypeError: cannot concatenate 'str' and 'int' objects >>> The expected behaviour is what Python 2.2 does, which is >>> def add(a, b): ... return a + b ... >>> add(a=3) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: add() takes exactly 2 non-keyword arguments (1 given) >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-31 02:04 Message: Logged In: YES user_id=80475 Fixed. See: Python/ceval.c 2.363 Lib/test/test_extcall.py 1.20 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 09:42 Message: Logged In: YES user_id=80475 Attaching a patch (actually a band-aid temporary fix). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 05:37 Message: Logged In: YES user_id=80475 Jeremy, it looks like this bug was part of your patches on 2/5/2003. CVS runs the code the day before, but not on the day after. The culprit is likely in taking the fast_function() path which bypasses the usual keyword argument handling. See ceval.c 2.348 and the related changes to sysmodule.c and ceval.h. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 04:23 Message: Logged In: YES user_id=80475 def f(a,b): print a, b def g(a,b,**kw): print a, b, kw f(c=3) # prints c 3 g(c=3) # raises correct error for non-keyword arguments. So, the restated version of the problem is that: when keyword arguments are passed to a function not defining **kw, then the keyword in interpreted as a single for the first positional argument and the keyword value as the second positional argument. Weird and bad! Reverting to earlier versions of getargs.c did not help. Likewise the dict(red=3, blue=4) patch is not the culprit. The prime suspect is now the function call optimizations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-07 02:54 Message: Logged In: YES user_id=80475 Ouch! This is a bad one. Bumping up the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733667&group_id=5470 From noreply@sourceforge.net Sat May 31 15:17:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 07:17:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-746012 ] PACKAGE_* in pyconfig.h Message-ID: <E19M7Am-00056Q-00@sc8-sf-web4.sourceforge.net> Bugs item #746012, was opened at 2003-05-30 07:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746012&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: PACKAGE_* in pyconfig.h Initial Comment: Is it intentional that in 2.3 pyconfig.h includes PACKAGE_* definitions? It causes lot of warnings when building modules (and maybe some other problems). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-31 10:17 Message: Logged In: YES user_id=33168 These seem to have been added when upgrading to autoconf 2.53. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746012&group_id=5470 From noreply@sourceforge.net Sat May 31 20:21:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 12:21:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-742911 ] Memory fault on complex weakref/weakkeydict delete Message-ID: <E19MBuk-0000TP-00@sc8-sf-web2.sourceforge.net> Bugs item #742911, was opened at 2003-05-24 18:29 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Guido van Rossum (gvanrossum) Summary: Memory fault on complex weakref/weakkeydict delete Initial Comment: Attached find two modules which together form a test-case. The cache.py file is ripped out of a production system (OpenGLContext), and I am seeing memory faults under both Python 2.2.2 and 2.2.3 when I run the code. Under 2.2.2 while single-stepping through the code I was able to provoke an error-message: Fatal Python error: GC object already in linked list The error message doesn't show up under 2.2.3, but the memory-fault does. Modules here don't use any extension modules, so there shouldn't be any loose memory references or the like. Note, you'll likely need to make weakkeydictionary's __delitem__ use keys instead of iterkeys to even get to the crashing. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-31 15:21 Message: Logged In: YES user_id=34901 2.2.3 fixes the original problem on Win2k. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-29 17:35 Message: Logged In: YES user_id=33168 2.3 works for me with the original, but didn't before. Redhat 9. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-05-29 16:47 Message: Logged In: YES user_id=2772 Just one question: does the final test-case cover the original bug? I have a redhat 9 system with Python 2.2.2, and temp2.py runs just fine: $ python2 temp2.py <__main__.Oops object at 0x8162ecc> $ The Python version is: Python 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 I have not tried any other version of the test-case. I also didn't try a non-redhat version, so it's barely possible that some patch they apply affected this issue. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-29 10:53 Message: Logged In: YES user_id=31435 Just changed Resolution to Fixed. Thanks everyone! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-29 10:35 Message: Logged In: YES user_id=6380 Thanks to Tim for the analysis, to Neal for the simplified test, and to Mike for the bug report! The fix was actually simple: clear the weak ref list *before* calling __del__ or clearing __dict__. This is the same order as used by classic classes, so can't be wrong. Applied to 2.2.3 branch and 2.3 trunk, with test case. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-05-28 21:16 Message: Logged In: YES user_id=34901 To give timeline: This is from real-life code (PyOpenGL's OpenGLContext demo/teaching module). It's currently about to go beta, with a release date target of end-of-summer. I've worked around the problem for the most common case w/in the system (exiting from the VRML browser), but that work-around's not usable for end-user long-running projects until the users can deallocate the scenegraph to load another (i.e. go from world to world within a single run of the application). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 19:26 Message: Logged In: YES user_id=31435 That's cool. The analysis is much easier to follow if you run Neal's little program, which crashes right away in a debug build. Then the analysis just follows the call stack, and it's instantly obvious (if you know to look for it <wink>) that we're trying to deallocate a single object twice. One thing subtype_delloc does that instance_dealloc doesn't is clear the instance dict before clearing the weakrefs. Clearing the instance dict can end up executing anything, and in this case does, in particular materializing a strong reference to the object we're in the middle of deallocating (via a weakref that hasn't been cleared). That seems to be the key point. Mike found the problem in 2.2.2, I believe in his real-life OpenGL code. That's why I'm keen to see it fixed for 2.2.3. I'll be in the office Thursday, BTW. Ah, here, I'll attach a simpler program that has the same kind of problem (temp2.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-28 18:16 Message: Logged In: YES user_id=6380 Tim, let's look at this when you're back in the office. My head spins from just reading the analysis below. Note that this is a 2.2 and 2.3 bug. I don't necessarily want to hold up the 2.2.3 release until this is fixed, unless we have a quick breakthrough. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-25 00:49 Message: Logged In: YES user_id=31435 Assigned to Guido, because I suspect the problem lies in the order subtype_dealloc does things. With reference to Neal's whittled-down case: when makeSome() ends, we decref i and then decref item. item's refcount hits 0 then. There's a weakref remaining to item (in CacheHolder.client), but subtype_dealloc doesn't clear the weakref at this point. First it clears item's instance dict. That contains the last strong reference to i. subtype_dealloc is inovked again, and clears i's instance dict, and then deals with the weak reference to i. The weakref to i has a callback associated with it, and CacheHolder.__call__() is invoked. That invokes self.client (), still a weakref to item, and because item's weakrefs still haven't been dealt with, self.client() returns item. Now we're hosed. item *had* a refcount of 0 at this point, and is still in the process of getting cleaned out by the first call to subtype_dealloc (it still thinks it's clearing item's instance dict). We already called _Py_ForgetReference on item when its refcount fell to 0. Its refcount gets boosted back to 1 by virtue of item getting returned by the self.client() weakref call. Cleaning out the frame for CacheHolder.__call__() knocks the refcount down to 0 again, and the second attempt to call _Py_ForgetReference on it blows up. In a release build, nothing visibly bad happens when I try it. It crashes if I add print client.items at the end of __call__ in a release-build run, though. Looks like that's just the luck of the draw after things have gone insane. I note that instance_dealloc deals with weakrefs much earlier in the process, so that when Neal makes Items a classic class instead, the eventual call to self.client() returns None (instead of items), and nothing bad happens.. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-24 22:53 Message: Logged In: YES user_id=31435 Outstanding, Neal -- thanks! I can confirm that this crashes in a current 2.3 debug build on Windows too. I'm feeling sick and won't pursue it now, though. When cleaning up from the call to makeSome() (the body of makeSome() has completed, and we're cleaning up its execution frame, decref'ing the locals), we're dying in _Py_ForgetReference with a NULL-pointer derefernce. The refcount on an Items object has just fallen to 0, and the code is trying to verify that the object is in the debug-build "list of all objects". But its prev and next pointers are both NULL -- it's not in the list, and simply trying to check that it is blows up. I don't have a theory for what's causing this, but it's probably not a good thing <heh>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 19:31 Message: Logged In: YES user_id=33168 I cut out a lot of stuff from the test. The new file is much more minimal, but still crashes for me in a 2.3 debug build. You only need the one file too (not both files). There is an issue with new style classes. If Items doesn't derive from object, I don't get a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742911&group_id=5470 From noreply@sourceforge.net Sat May 31 23:09:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 31 May 2003 15:09:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-734695 ] Function for creating/extracting CoreFoundation types Message-ID: <E19MEY1-00031E-00@sc8-sf-web4.sourceforge.net> Bugs item #734695, was opened at 2003-05-08 17:15 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470 Category: Macintosh Group: Feature Request >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Function for creating/extracting CoreFoundation types Initial Comment: pymactoolbox.h contains a number of functions for converting from CoreFoundation references to Python wrappers for those functions (e.g. CFTypeRefObj_New). Simularly there are functions for extracting the CoreFoundation reference from a wrapped Python object (e.g. CFTypeRefObj_Convert). It would be nice if CFTypeRefObj_New would automaticly create a more specialized Python wrapper if you pass it a CFArrayRef, this decreases the coupling between the python core and 3th party extension modules. Simularly CFTypeRefObj_Convert should "work" when passed a CFArrayRefObj. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-06-01 00:09 Message: Logged In: YES user_id=45365 Oops, sorry, I thought I had added it! It's in there now. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-05-29 22:55 Message: Logged In: YES user_id=580910 My initial tests were a little too easy, now that I've completely rebuild PyObjC I see: ImportError: Module did not provide routine: Carbon.CF: CFObj_New Shouldn't there be code in _CFmodule.c to make sure that the mactoolboxglue can find the two new functions? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-05-29 21:55 Message: Logged In: YES user_id=580910 The new functions seem to work just fine, and the implementation looks OK too. I think the current implementation is fine, automaticly converting only some types to/from their python equivalent would be confusing. Furthermore the current behaviour allows me to get as close as possible to 'toll-free bridging' , which means it should be possible to translate code examples that use this feature into Python without too many problems. Thanks for implementing this! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-05-27 23:43 Message: Logged In: YES user_id=45365 Implemented in CVS, but I have called the new generalized functions CFObj_New() and CFObj_Convert(). One issue is open to discussion: currently CFObj_New() expects a CFTypeRef object for which a wrapper is available. An alternative would be to use PyCF_CF2Python() otherwise (so CFNumber would get mapped to a Python int, etc). Similarly for CFObj_Convert(), which expects an object of one of the classes Carbon.CF implements. It could also fall back to using PyCF_Python2CF(). Let me know which solution is better. Also: the code is pretty much untested. Please test, and close this report when you're satisfied (and after answering the previous question). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=734695&group_id=5470