From noreply at sourceforge.net Thu Dec 1 11:32:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 02:32:14 -0800 Subject: [ python-Bugs-1370322 ] Bytecode problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 19:49 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Bytecode problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Thu Dec 1 11:40:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 02:40:51 -0800 Subject: [ python-Bugs-1350060 ] built-in method .__cmp__ Message-ID: Bugs item #1350060, was opened at 2005-11-07 08:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: built-in method .__cmp__ Initial Comment: Bound methods of built-in objects have a strange __cmp__/__hash__ combination: they compare equal only if their __self__ are identical, but they hash based on the hash of __self__ instead of its _Py_HashPointer(). Built-in methods should consistently be based on the identity *or* the equality of __self__. For reference, regular instance methods are based on the equality. So I propose to fix built-in method objects in the same way. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:40 Message: Logged In: YES user_id=4771 Sorry, my mistake: regular instance methods behave like built-in methods. They are both based on the identity of their 'self' but use its hash to compute their own hash. This bug report is thus only about why should the hash of methods and built-in methods depend on the hash of their 'self'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 From noreply at sourceforge.net Thu Dec 1 14:51:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 05:51:11 -0800 Subject: [ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser Message-ID: Bugs item #1246405, was opened at 2005-07-28 01:07 Message generated for change (Comment added) made by bernhard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2005-12-01 14:51 Message: Logged In: YES user_id=2369 Could this be the same problem as bug 1075984 ? URL: https://sourceforge.net/tracker/index.php?func=detail&aid=1075984&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-06 22:23 Message: Logged In: YES user_id=1247525 Yes I can try with different version of wx, but it will take time. Anyway for today here is in attachment the valgrind output on linux x86. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-05 05:34 Message: Logged In: YES user_id=33168 I don't have the problem with Python 2.3.4 and wx 2.5.5.1. Are you able to try different versions of wxPython? I notice that wx 2.6.2 is available. Are you able to run under valgrind or purify? If you run under valgrind, be sure to specify --suppressions=Misc/valgrind-python.supp The file is in the Python distribution. You can download it through SourceForge ViewCVS. ---------------------------------------------------------------------- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-05 00:05 Message: Logged In: YES user_id=1247525 Link is : http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863 Unfortunately, absolutely nothing has happened since I reported the bug. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 07:10 Message: Logged In: YES user_id=33168 Can you provide a link to the wx bug report? Has anything happend with it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 From noreply at sourceforge.net Thu Dec 1 16:12:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 07:12:33 -0800 Subject: [ python-Feature Requests-1370948 ] Start and end parameters for list.count() Message-ID: Feature Requests item #1370948, was opened at 2005-12-01 16:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1370948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Start and end parameters for list.count() Initial Comment: For lists and strings, the index() method has start and end parameters. For strings, the count() method has start and end parameters as well. But for lists, the count() method has no such parameters. I think it may be a good idea to allow start and end parameters for count() on lists as well, if only for consistency reasons. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1370948&group_id=5470 From noreply at sourceforge.net Thu Dec 1 22:50:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 13:50:46 -0800 Subject: [ python-Bugs-1371247 ] locale.windows_locale Message-ID: Bugs item #1371247, was opened at 2005-12-01 21:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: locale.windows_locale Initial Comment: from locale.py: # # this maps windows language identifiers (as used on Windows 95 and # earlier) to locale strings. # # NOTE: this mapping is incomplete. If your language is missing, please # submit a bug report to Python bug manager, which you can find via: # http://www.python.org/dev/ # Make sure you include the missing language identifier and the suggested # locale code. # The complete mapping table can be found here: http://www.dx21.com/SCRIPTING/VBSCRIPT/LCID.ASP ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 From noreply at sourceforge.net Thu Dec 1 23:30:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 14:30:52 -0800 Subject: [ python-Bugs-1371247 ] locale.windows_locale Message-ID: Bugs item #1371247, was opened at 2005-12-01 21:50 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: locale.windows_locale Initial Comment: from locale.py: # # this maps windows language identifiers (as used on Windows 95 and # earlier) to locale strings. # # NOTE: this mapping is incomplete. If your language is missing, please # submit a bug report to Python bug manager, which you can find via: # http://www.python.org/dev/ # Make sure you include the missing language identifier and the suggested # locale code. # The complete mapping table can be found here: http://www.dx21.com/SCRIPTING/VBSCRIPT/LCID.ASP ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2005-12-01 22:30 Message: Logged In: YES user_id=731668 I believe there's a small typo in that page. Spanish 1034 says hex 0x0C0A when hex(1034) is 0x040A The rest seems correct (hex and int values match). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 From noreply at sourceforge.net Fri Dec 2 06:22:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 21:22:20 -0800 Subject: [ python-Bugs-1370197 ] memory leak - ast_error_finish Message-ID: Bugs item #1370197, was opened at 2005-11-30 08:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak - ast_error_finish Initial Comment: http://svn.python.org/view/python/trunk/Python/ast.c? rev=41486&view=markup function ast_error_finish It first gets the errstr, for a possible early out. If there is an error string, it is increfed, but it is not decrefed on the other early outs. (lineno==-1 and failure to build a tmp. """ Py_INCREF(errstr); lineno = PyInt_AsLong(PyTuple_GetItem(value, 1)); if (lineno == -1) return; Py_DECREF(value); loc = PyErr_ProgramText(filename, lineno); if (!loc) { Py_INCREF(Py_None); loc = Py_None; } tmp = Py_BuildValue("(ziOO)", filename, lineno, Py_None, loc); Py_DECREF(loc); if (!tmp) return; value = Py_BuildValue("(OO)", errstr, tmp); Py_DECREF(errstr); """ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-01 21:22 Message: Logged In: YES user_id=33168 ISTM that we don't need the INCREF or DECREF for errstr. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470 From noreply at sourceforge.net Fri Dec 2 07:17:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 22:17:32 -0800 Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *= Message-ID: Bugs item #1355842, was opened at 2005-11-13 11:17 Message generated for change (Comment added) made by connelly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect Decimal-float behavior for += and *= Initial Comment: The += and *= operators have strange behavior when the LHS is a Decimal and the RHS is a float (as of 2005-11-13 CVS decimal.py). Example: >>> d = Decimal('1.02') >>> d += 2.1 >>> d NotImplemented A blatant violation of "Errors should never pass silently." Also, a bad error description is produced for the *= operator: >>> d = Decimal('1.02') >>> d *= 2.9 Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- >Comment By: Connelly (connelly) Date: 2005-12-02 06:17 Message: Logged In: YES user_id=1039782 The += and *= operations also give the same strange behavior when the LHS is a Decimal and the RHS is str or unicode: >>> d = Decimal("1.0") >>> d += "5" >>> d NotImplemented >>> d = Decimal("1.0") >>> d *= "1.0" Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 04:43 Message: Logged In: YES user_id=33168 Hmmm. __add__ returns NotImplemented which works with classic classes, but not new-style classes. I wonder if NotImplementedError is supposed to be raised for new-style classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 From noreply at sourceforge.net Fri Dec 2 14:43:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 05:43:42 -0800 Subject: [ python-Bugs-1368481 ] python.dir still refers to python-whatsnew23 Message-ID: Bugs item #1368481, was opened at 2005-11-28 19:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: python.dir still refers to python-whatsnew23 Initial Comment: In the tarball with the GNU info version of the documentation, the file python.dir still refers to a node python-whatsnew23 which doesn't exist. It should be python-whatsnew24. This bug is also present in SVN in both release24-maint branch and trunk. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-02 14:43 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in rev. 41579, 41580(2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368481&group_id=5470 From noreply at sourceforge.net Fri Dec 2 17:20:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 08:20:34 -0800 Subject: [ python-Bugs-1371826 ] distutils is silent about multiple -I/-L/-R Message-ID: Bugs item #1371826, was opened at 2005-12-02 10:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371826&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: distutils is silent about multiple -I/-L/-R Initial Comment: GCC (actually, most compilers I think) allows you to specify -L, -I and -R multiple times. In contrast, distutils expects on of them with a colon-separated list of directories. It only pays attention to the last one of any of those three flags. I've been bitten by this difference a couple times in recent weeks. It seems that distutils should warn when any of these flags are given multiple times or (better yet) should conform more to common compiler usage and allow them to be given multiple times, collecting all values together in a list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371826&group_id=5470 From noreply at sourceforge.net Fri Dec 2 20:14:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 11:14:42 -0800 Subject: [ python-Bugs-1370197 ] memory leak - ast_error_finish Message-ID: Bugs item #1370197, was opened at 2005-11-30 11:41 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak - ast_error_finish Initial Comment: http://svn.python.org/view/python/trunk/Python/ast.c? rev=41486&view=markup function ast_error_finish It first gets the errstr, for a possible early out. If there is an error string, it is increfed, but it is not decrefed on the other early outs. (lineno==-1 and failure to build a tmp. """ Py_INCREF(errstr); lineno = PyInt_AsLong(PyTuple_GetItem(value, 1)); if (lineno == -1) return; Py_DECREF(value); loc = PyErr_ProgramText(filename, lineno); if (!loc) { Py_INCREF(Py_None); loc = Py_None; } tmp = Py_BuildValue("(ziOO)", filename, lineno, Py_None, loc); Py_DECREF(loc); if (!tmp) return; value = Py_BuildValue("(OO)", errstr, tmp); Py_DECREF(errstr); """ ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2005-12-02 14:14 Message: Logged In: YES user_id=764593 No, though it took me a *long* time to see why, because the &value pointer is reused. As best I understand it, PyErr_Fetch may leave (the initial value of) value with the only reference to errstr. There is a Py_DECREF(value) after successfully retrieving a line number, but before using errstr to build the (new value of) value for PyErr_Restore. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-02 00:22 Message: Logged In: YES user_id=33168 ISTM that we don't need the INCREF or DECREF for errstr. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470 From noreply at sourceforge.net Fri Dec 2 20:47:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 11:47:07 -0800 Subject: [ python-Bugs-1371937 ] minidom namespace problems Message-ID: Bugs item #1371937, was opened at 2005-12-02 14: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=1371937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: minidom namespace problems Initial Comment: Noted on c.l.py: the minidom writexml() function doesn't tidy up namespace declarations, so you can output documents that have incorrect namespace declarations. DOM Level 3, appendix B, specifies an algorithm for normalizing namespaces; see http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html . minidom probably needs to acquire the normalizeNamespace method, and then writexml() can call it before doing its work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371937&group_id=5470 From noreply at sourceforge.net Sat Dec 3 03:08:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 18:08:17 -0800 Subject: [ python-Bugs-1352621 ] SVN webbrowser.py fix 41419 didn't Message-ID: Bugs item #1352621, was opened at 2005-11-09 14:26 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1352621&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: SVN webbrowser.py fix 41419 didn't Initial Comment: The new fix of setting remote_background to True and adding an & in the "simplier command" case can't work. If remote_background is True, then the first os.system call will always succeed and thus the second one will never be called. So if the web browser isn't already running, it will never start up. As I alluded to in my previous bug submission 1338995, the real fix will involve using the subprocess module -- I will try to find some time to develop and test a patch and submit it. ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-12-02 18:08 Message: Logged In: YES user_id=131838 See bug #1338995 and patch #1372125 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1352621&group_id=5470 From noreply at sourceforge.net Sat Dec 3 03:12:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 18:12:31 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-12-02 18:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 12:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 20:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 14:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 05:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 11:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 04:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Sun Dec 4 04:47:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Dec 2005 19:47:22 -0800 Subject: [ python-Bugs-1372650 ] Cookie and multiple names Message-ID: Bugs item #1372650, was opened at 2005-12-03 18: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=1372650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 From noreply at sourceforge.net Sun Dec 4 11:30:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 02:30:48 -0800 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 10:08 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-04 10:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 19:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-23 04:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 07:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 11:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 10:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 10:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Sun Dec 4 11:53:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 02:53:10 -0800 Subject: [ python-Bugs-1372770 ] email.Header should preserve original FWS Message-ID: Bugs item #1372770, was opened at 2005-12-04 02: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=1372770&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nathan Herring (nherring) Assigned to: Nobody/Anonymous (nobody) Summary: email.Header should preserve original FWS Initial Comment: The Header class describes its operation as using the continuation_ws parameter, prepending the value to continuation lines. This has the byproduct of possibly converting pre-existing FWS in a header, as evidenced by mailman 2.1.6 which exposes the problem. If the Header class is passed pre-existing Header lines, which in the mailman case is from the original message, and, without any manipulation, ask it for the encoded version, it replaces the original folding with the continuation_ws characters. Given that RFC 2822 unfolding consists only of removing CRLFs, exchanging out the FWS characters changes the logical content of a header value. Standard folding of us-ascii text should only consist of introducing line breaks in front of original FWS in the header line. In the case where the encoding of the source string requires multiple adjacent RFC 2047 encoded-words (either due to disparate encodings or text length), then FWS can be freely inserted and is treated as an artifact of the encoding. It is ignored on reading and as such it doesn't affect the logical content of the header value. It's in this latter case that the continuation_ws parameter should be used. e.g., #!/usr/bin/python -d from email.Header import Header s = "Thread-Topic: Use of tabs when folding header lines -- increasing subject\n length as a test\n" print Header(s, 'us-ascii', None, None, '\t') This script will have replaced the space in front of the word "length" with a tab. It should retain that space and not convert it to the continuation_ws character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372770&group_id=5470 From noreply at sourceforge.net Sun Dec 4 15:44:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 06:44:04 -0800 Subject: [ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly Message-ID: Bugs item #1115886, was opened at 2005-02-04 01:27 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeong-Min Lee (falsetru) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.splitext don't handle unix hidden file correctly Initial Comment: I expected this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/.Hiddenfile', '') but got this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/', '.Hiddenfile') ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 14:44 Message: Logged In: YES user_id=261020 -1 I hate to be a stick-in-the-mud, but the existing behaviour is what I would expect, and seems to be regular -- always picks the last dot: >>> os.path.splitext('a/b/c/foo.bar') ('a/b/c/foo', '.bar') >>> os.path.splitext('a/b/c/f.oo.bar') ('a/b/c/f.oo', '.bar') >>> os.path.splitext('a/b/c/.foo') ('a/b/c/', '.foo') >>> os.path.splitext('a/b/c/.foo.txt') ('a/b/c/.foo', '.txt') Changing it would surely break somebody's code too, of course. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 22:05 Message: Logged In: YES user_id=1188172 Interestingly, altering the behaviour of splitext in such a way does not contradict the documentation, which is: """ Split the pathname path into a pair (root, ext) such that root + ext == path, and ext is empty or begins with a period and contains at most one period. """ Personally I'm in favour of this change (on Unix it makes sense, while on Windows you can hardly find an "extension-only" file). ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2005-06-13 15:12 Message: Logged In: YES user_id=147070 from test_posixpath.py :: self.assertEqual(posixpath.splitext(".ext"), ("", ".ext")) IMHO should then return (".ext",""). if this is desired :: if i<=p.rfind('/'): return p, '' else: return p[:i], p[i:] should do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 From noreply at sourceforge.net Sun Dec 4 16:08:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 07:08:57 -0800 Subject: [ python-Bugs-1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC Message-ID: Bugs item #1222790, was opened at 2005-06-17 13:18 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Winfried Harbecke (wharbecke) >Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer does not set FD_CLOEXEC Initial Comment: The SimpleXMLRPCServer constructor does not set FD_CLOEXEC on the socket that listens for new connections. When the XML RPC server spawns other daemons, and the XML RPC server is stopped before the spawned daemon dies, the spawned daemon will hog the inherited socket and the XML RPC server will be unable to open its listening socket again (ADDR_IN_USE). Since there is no reason why a spawned process should inherit the listen socket, the close-on-exec flag should be used to prevent inheriting the socket to spawned processes. import socket + import fcntl import xmlrpclib ... def __init__(self, addr, ... SocketServer.TCPServer.__init__(self, addr, requestHandler) ! # close on exec - spawned shell should not access the service ! # listen socket ! flags = fcntl.fcntl(self.fileno(), fcntl.F_GETFD) ! flags |= fcntl.FD_CLOEXEC ! fcntl.fcntl(self.fileno(), fcntl.F_SETFD, flags) ! There is a similar fix in the Zope distribution, see http://archives.free.net.ph/message/20030719.201708.f3a aed4d.html ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 10:08 Message: Logged In: YES user_id=11375 Fixed in rev41585. SimpleXMLRPCServer now sets allow_reuse_address to True, and also sets FD_CLOEXEC. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-06-28 22:58 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-06-28 22:56 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-06-28 22:55 Message: Logged In: YES user_id=81797 I don't fully understand the implications of this, but I'd vote for a fix of this as well. It's pretty painful to use the SimpleXMLRPCServer for development because of the wait time required between tests until the OS clears the "in use" flag. I was thining that it was not setting the flag for immediate re-use of the socket, though. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222790&group_id=5470 From noreply at sourceforge.net Sun Dec 4 16:16:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 07:16:20 -0800 Subject: [ python-Bugs-792570 ] SimpleXMLRPCServer cannot handle large requests Message-ID: Bugs item #792570, was opened at 2003-08-21 11:37 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792570&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marc-Andr? Morissette (morissette) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer cannot handle large requests Initial Comment: SimpleXMLRPCServer throws a WSAEINTR ioerror on large XML-RPC requests. Under Windows, the socket.read() method cannot seem to handle large (tens of megabytes) reads (could be a Python specific problem). This means that very large XML-RPC requests can cause the exception. Here is a tentative patch against 2.2.3 to fix the problem. It should be easy to port it to 2.3 --- /cygdrive/c/Python22/Lib/SimpleXMLRPCServer.py 2003-07-09 14:16:52.000000000 -0400 +++ /cygdrive/z/SimpleXMLRPCServer.py 2003-08-21 11:01:19.000000000 -0400 @@ -73,6 +73,8 @@ import SocketServer import BaseHTTPServer import sys +import cStringIO class SimpleXMLRPCRequestHandler (BaseHTTPServer.BaseHTTPRequestHandler): """Simple XML-RPC request handler class. @@ -95,7 +97,14 @@ try: # get arguments - data = self.rfile.read(int(self.headers["content- length"])) + max_chunk_size = 10000000 + content_length = int(self.headers["content- length"]) + buffer = cStringIO.StringIO() + for offset in range(0, content_length, max_chunk_size): + chunk_size = min(content_length - offset, max_chunk_size) + buffer.write(self.rfile.read(chunk_size)) + data = buffer.getvalue() + buffer.close() params, method = xmlrpclib.loads(data) # generate response ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 10:16 Message: Logged In: YES user_id=11375 Why does SimpleXMLRPCServer need to be fixed if socket.read() is choking? Shouldn't socket.read() be fixed instead? noplay: do you mean you're seeing this bug happen on Linux? I don't use Windows, so being able to reproduce the problem on Linux would be very useful. ---------------------------------------------------------------------- Comment By: julien duponchelle (noplay) Date: 2005-10-21 05:36 Message: Logged In: YES user_id=446148 I have the same problem with Python2.4 with windows and linux version. If XML-RPC server reads to large buffer, it returns only a part of the buffer. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 08:26 Message: Logged In: YES user_id=1188172 Marc-Andre, can you still reproduce this with Python 2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792570&group_id=5470 From noreply at sourceforge.net Sun Dec 4 16:38:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 07:38:48 -0800 Subject: [ python-Bugs-792570 ] SimpleXMLRPCServer cannot handle large requests Message-ID: Bugs item #792570, was opened at 2003-08-21 11:37 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792570&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marc-Andr? Morissette (morissette) >Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer cannot handle large requests Initial Comment: SimpleXMLRPCServer throws a WSAEINTR ioerror on large XML-RPC requests. Under Windows, the socket.read() method cannot seem to handle large (tens of megabytes) reads (could be a Python specific problem). This means that very large XML-RPC requests can cause the exception. Here is a tentative patch against 2.2.3 to fix the problem. It should be easy to port it to 2.3 --- /cygdrive/c/Python22/Lib/SimpleXMLRPCServer.py 2003-07-09 14:16:52.000000000 -0400 +++ /cygdrive/z/SimpleXMLRPCServer.py 2003-08-21 11:01:19.000000000 -0400 @@ -73,6 +73,8 @@ import SocketServer import BaseHTTPServer import sys +import cStringIO class SimpleXMLRPCRequestHandler (BaseHTTPServer.BaseHTTPRequestHandler): """Simple XML-RPC request handler class. @@ -95,7 +97,14 @@ try: # get arguments - data = self.rfile.read(int(self.headers["content- length"])) + max_chunk_size = 10000000 + content_length = int(self.headers["content- length"]) + buffer = cStringIO.StringIO() + for offset in range(0, content_length, max_chunk_size): + chunk_size = min(content_length - offset, max_chunk_size) + buffer.write(self.rfile.read(chunk_size)) + data = buffer.getvalue() + buffer.close() params, method = xmlrpclib.loads(data) # generate response ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 10:38 Message: Logged In: YES user_id=11375 It turns out that on my Mac socket.read() runs into trouble around 15Mb, so I could reproduce the problem. Fix committed in rev 41586; it's the same principle as the suggested change, but the code is rewritten for better scalability (appending to a list instead of using a cStringIO). Thanks! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 10:16 Message: Logged In: YES user_id=11375 Why does SimpleXMLRPCServer need to be fixed if socket.read() is choking? Shouldn't socket.read() be fixed instead? noplay: do you mean you're seeing this bug happen on Linux? I don't use Windows, so being able to reproduce the problem on Linux would be very useful. ---------------------------------------------------------------------- Comment By: julien duponchelle (noplay) Date: 2005-10-21 05:36 Message: Logged In: YES user_id=446148 I have the same problem with Python2.4 with windows and linux version. If XML-RPC server reads to large buffer, it returns only a part of the buffer. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 08:26 Message: Logged In: YES user_id=1188172 Marc-Andre, can you still reproduce this with Python 2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792570&group_id=5470 From noreply at sourceforge.net Sun Dec 4 16:52:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 07:52:35 -0800 Subject: [ python-Bugs-1372650 ] Cookie and multiple names Message-ID: Bugs item #1372650, was opened at 2005-12-04 03:47 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 15:52 Message: Logged In: YES user_id=261020 I don't get it: >>> import Cookie >>> c = Cookie.SimpleCookie() >>> c.load("foo=bar; bar=baz") >>> c Where's the problem? In general, don't pay too much attention to that standard, BTW: http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 From noreply at sourceforge.net Sun Dec 4 17:07:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 08:07:25 -0800 Subject: [ python-Bugs-1372650 ] Cookie and multiple names Message-ID: Bugs item #1372650, was opened at 2005-12-03 18:47 Message generated for change (Comment added) made by valankar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. ---------------------------------------------------------------------- >Comment By: Viraj Alankar (valankar) Date: 2005-12-04 07:07 Message: Logged In: YES user_id=107970 Basically, sometimes a web client will send 2 instances of the same name: Cookie: mycookie=foo; mycookie=bar The specs say that the first one is the one that should be used. The other cookies listed are the inherited ones from paths that a prefix of the current URL. When this is parsed by the Cookie module, mycookie gets set to bar when it should be foo. Another example might be: Cookie: mycookie=foo; path=bar Cookie: mycookie=foo; path=baz In this case there should be 2 cookies with the name 'mycookie'. The uniqueness is determined by the different paths. Thanks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 06:52 Message: Logged In: YES user_id=261020 I don't get it: >>> import Cookie >>> c = Cookie.SimpleCookie() >>> c.load("foo=bar; bar=baz") >>> c Where's the problem? In general, don't pay too much attention to that standard, BTW: http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 From noreply at sourceforge.net Sun Dec 4 18:18:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 09:18:12 -0800 Subject: [ python-Bugs-1041501 ] SimpleXMLRPCServer example is broken Message-ID: Bugs item #1041501, was opened at 2004-10-06 10:31 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1041501&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer example is broken Initial Comment: Section 11.21.1 of the library reference (SimpleXMLRPCServer Objects) includes this class definition: class MyFuncs: def div(self, x, y) : return div(x,y) This is given to the sample server as in instance object. The problem is that there is no global div() function so attempting to call div() from XML-RPC returns a Fault with a NameError. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 12:18 Message: Logged In: YES user_id=11375 Fixed the CGIXMLRPCRequestHandler, too; thanks again. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2005-06-23 08:39 Message: Logged In: YES user_id=49695 Reopened because a similar fix is needed on the page 11.23.2 CGIXMLRPCRequestHandler ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-10-08 14:34 Message: Logged In: YES user_id=11375 Fixed; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1041501&group_id=5470 From noreply at sourceforge.net Sun Dec 4 18:22:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 09:22:56 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 18:08 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 11:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 20:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 14:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 22:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 15:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 16:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 07:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 13:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 06:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 12:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 10:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Sun Dec 4 18:26:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 09:26:27 -0800 Subject: [ python-Bugs-901198 ] strange behaviour of xmlrpclib.Server proxy Message-ID: Bugs item #901198, was opened at 2004-02-20 11:47 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901198&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andreas Eisele (eisele) >Assigned to: A.M. Kuchling (akuchling) Summary: strange behaviour of xmlrpclib.Server proxy Initial Comment: Not quite sure this is a bug, but the problem caused me considerable time to track down (Python 2.3.2 on Solaris). assume proxy is a variable for a server proxy created with xmlrpclib.Server(), but sometimes it is None (assume a default argument to a function). The comparisons if proxy != None: or if proxy: fail with (to me) rather incomprehensible error messages. However, the test if proxy is not None: does what I expect. Is this a feature or a bug? Thanks a lot for looking into it. Andreas Eisele ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 12:26 Message: Logged In: YES user_id=11375 Note that comparisons to None are better written as 'if proxy is not None'; they're faster that way. There's a more general problem here: any Python special methods are forwarded via XML-RPC, so if you write 'proxy + 5', it tries to call __coerce__ and fails; if you write 'proxy[5]', it calls __getitem__ and fails. One fix would be to implement all of these methods on ServerProxy. Another would be to ignore methods beginning and ending with '__' in the __getattr__, but then you couldn't call such methods at all. I suggest that there's really nothing to do here; if you try certain operations on a ServerProxy, they'll fail. Closing as "won't fix". ---------------------------------------------------------------------- Comment By: Gerhard Reitmayr (merl7n) Date: 2004-11-11 16:21 Message: Logged In: YES user_id=12764 I also encountered the same bug. It appears that the ServerProxy class does not implement the necessary operator methods and therefore the defined __getattr__ method takes over and gets it wrong. Adding the following methods to ServerProxy resolves the issue: def __eq__(self, other): return self is other def __ne__(self, other): return self is not other def __nonzero__(self): return True It would be great, if this could be fixed in xmlrpclib. Thanks, Gerhard Reitmayr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901198&group_id=5470 From noreply at sourceforge.net Sun Dec 4 19:16:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 10:16:33 -0800 Subject: [ python-Bugs-1349316 ] xmlrpclib does not use http proxy Message-ID: Bugs item #1349316, was opened at 2005-11-05 21:07 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: greatred (greatred) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib does not use http proxy Initial Comment: The xmlrpclib class ServerProxy does not seem to be able to make use of a HTTP proxy. This makes it unusable behind a firewall where the proxy is the only access to the destination server. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 13:16 Message: Logged In: YES user_id=11375 I have a documentation change ready to go; will check that in once I get permission. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 05:32 Message: Logged In: YES user_id=38376 To handle this, you can use a custom transport. Here's an example: http://lowlife.jp/nobonobo/wiki/xmlrpcwithproxy.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 From noreply at sourceforge.net Sun Dec 4 19:16:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 10:16:51 -0800 Subject: [ python-Bugs-1372650 ] Cookie and multiple names Message-ID: Bugs item #1372650, was opened at 2005-12-04 03:47 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 18:16 Message: Logged In: YES user_id=261020 OK, I see. I agree that it's a bug, but I'm undecided whether the existing behaviour should be fixed. It's true that clients are supposed to (and do) send the most specific cookie last, so this bug could cause servers to see the cookie from, eg path '/cgi-bin' instead of from path '/mystuff/cgi-bin'. However, module Cookie is old and stable, and a patch might break servers expecting the current behaviour. I *suppose* such breakage is fairly unlikely, so I wouldn't object to a patch. I certainly don't see anybody objecting to a patch to add a new method to allow access to multiple cookies of the same name without altering the existing dict interface (repr() could change, but not eg. .get()). Either way, I suspect a patch is only likely to appear from somebody who is actually using such cookies, though :-) ---------------------------------------------------------------------- Comment By: Viraj Alankar (valankar) Date: 2005-12-04 16:07 Message: Logged In: YES user_id=107970 Basically, sometimes a web client will send 2 instances of the same name: Cookie: mycookie=foo; mycookie=bar The specs say that the first one is the one that should be used. The other cookies listed are the inherited ones from paths that a prefix of the current URL. When this is parsed by the Cookie module, mycookie gets set to bar when it should be foo. Another example might be: Cookie: mycookie=foo; path=bar Cookie: mycookie=foo; path=baz In this case there should be 2 cookies with the name 'mycookie'. The uniqueness is determined by the different paths. Thanks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 15:52 Message: Logged In: YES user_id=261020 I don't get it: >>> import Cookie >>> c = Cookie.SimpleCookie() >>> c.load("foo=bar; bar=baz") >>> c Where's the problem? In general, don't pay too much attention to that standard, BTW: http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 From noreply at sourceforge.net Sun Dec 4 19:47:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 10:47:07 -0800 Subject: [ python-Bugs-1349316 ] xmlrpclib does not use http proxy Message-ID: Bugs item #1349316, was opened at 2005-11-05 21:07 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: greatred (greatred) >Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib does not use http proxy Initial Comment: The xmlrpclib class ServerProxy does not seem to be able to make use of a HTTP proxy. This makes it unusable behind a firewall where the proxy is the only access to the destination server. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 13:16 Message: Logged In: YES user_id=11375 I have a documentation change ready to go; will check that in once I get permission. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 05:32 Message: Logged In: YES user_id=38376 To handle this, you can use a custom transport. Here's an example: http://lowlife.jp/nobonobo/wiki/xmlrpcwithproxy.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 From noreply at sourceforge.net Sun Dec 4 19:52:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 10:52:55 -0800 Subject: [ python-Bugs-878275 ] Handle: class MyTest(unittest.TestSuite) Message-ID: Bugs item #878275, was opened at 2004-01-16 14:22 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Steve Purcell (purcell) Summary: Handle: class MyTest(unittest.TestSuite) Initial Comment: TestCases are supposed to be derived from unittest.TestCase; however, if they are derived from unittest.TestSuite, the traceback is inexplicable and hard to diagnose: Traceback (most recent call last): File "C:/pydev/tmp.py", line 10, in -toplevel- unittest.TextTestRunner(verbosity=2).run(suite) File "C:\PY24\lib\unittest.py", line 690, in run test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) TypeError: 'str' object is not callable Let's either improve the error message or make it possible to derive from TestSuite. The above traceback is produced by the following script: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite() suite.addTest(unittest.makeSuite(TestStats)) unittest.TextTestRunner(verbosity=2).run(suite) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 18:52 Message: Logged In: YES user_id=261020 Just to be clear: The issue with jlgijsbers' odd error message (in his 2004-11-07 followup) is not that a TestSuite is passed to the TestSuite constructor, but rather that he's passing in a class, not an instance. The error would show up a bit earlier if a check were added to TestSuite.addTest(): if type(test) == type: raise TypeError('addTest argument 1 must be instance, not class') I will post that line as a patch if anyone emails me to request it! ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 15:53 Message: Logged In: YES user_id=469548 Well, the error message above has been fixed, but here's another equally confusing variant: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite([TestStats]) unittest.TextTestRunner(verbosity=2).run(suite) giving: Traceback (most recent call last): File "test-foo.py", line 8, in ? unittest.TextTestRunner(verbosity=2).run(suite) File "/home/johannes/python/Lib/unittest.py", line 695, in run test(result) File "/home/johannes/python/Lib/unittest.py", line 426, in __call__ test(result) File "/home/johannes/python/Lib/unittest.py", line 396, in __init__ self.addTests(tests) File "/home/johannes/python/Lib/unittest.py", line 416, in addTests for test in tests: TypeError: iteration over non-sequence so I'm leaving this open. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 13:39 Message: Logged In: YES user_id=129426 patch is at #1061904 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470 From noreply at sourceforge.net Sun Dec 4 20:13:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 11:13:14 -0800 Subject: [ python-Bugs-1164912 ] xmlrpclib.DateTime.decode() should stringify argument Message-ID: Bugs item #1164912, was opened at 2005-03-16 19:27 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164912&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Allan Saddi (asaddi) >Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib.DateTime.decode() should stringify argument Initial Comment: DateTime.decode() is allowing unicode strings to be assigned to self.value. Python 2.4 (#2, Feb 17 2005, 09:44:14) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> from xmlrpclib import * >>> s = loads(dumps((DateTime(),), methodresponse=True)) >>> print s ((,), None) When this DateTime object with unicode value is subsequently passed to dumps(), dumps() will either return the result as a unicode string (which I don't believe is the correct behavior), or it will raise a UnicodeDecodeError. >>> dumps(s[0]) u'\n\n20050316T16: 10:20\n\n\n' (UnicodeDecodeError is raised when marshalling other unicode strings that do not have a simple ascii representation with the resultant DateTime.) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 14:13 Message: Logged In: YES user_id=11375 I've added the str() call to xmlrpclib in rev41594. Thanks for reporting this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164912&group_id=5470 From noreply at sourceforge.net Sun Dec 4 20:24:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 11:24:00 -0800 Subject: [ python-Bugs-878275 ] Handle: class MyTest(unittest.TestSuite) Message-ID: Bugs item #878275, was opened at 2004-01-16 14:22 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Steve Purcell (purcell) Summary: Handle: class MyTest(unittest.TestSuite) Initial Comment: TestCases are supposed to be derived from unittest.TestCase; however, if they are derived from unittest.TestSuite, the traceback is inexplicable and hard to diagnose: Traceback (most recent call last): File "C:/pydev/tmp.py", line 10, in -toplevel- unittest.TextTestRunner(verbosity=2).run(suite) File "C:\PY24\lib\unittest.py", line 690, in run test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) TypeError: 'str' object is not callable Let's either improve the error message or make it possible to derive from TestSuite. The above traceback is produced by the following script: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite() suite.addTest(unittest.makeSuite(TestStats)) unittest.TextTestRunner(verbosity=2).run(suite) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 19:24 Message: Logged In: YES user_id=261020 In fact in jlgijsbers' case (TestSuite class passed to TestSuite, rather than another bug: TestCase class passed to TestSuite), that check just pushes the problem back a bit: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite([TestStats('testtwo')]) unittest.TextTestRunner(verbosity=2).run(suite) TypeError: 'str' object is not callable Another test could be added to TestSuite addTest(): if not callable(test): raise TypeError('addTest argument 1 must be callable') Again, though it does makes the error clearer, it seems debatable that it's worth the change... ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 18:52 Message: Logged In: YES user_id=261020 Just to be clear: The issue with jlgijsbers' odd error message (in his 2004-11-07 followup) is not that a TestSuite is passed to the TestSuite constructor, but rather that he's passing in a class, not an instance. The error would show up a bit earlier if a check were added to TestSuite.addTest(): if type(test) == type: raise TypeError('addTest argument 1 must be instance, not class') I will post that line as a patch if anyone emails me to request it! ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 15:53 Message: Logged In: YES user_id=469548 Well, the error message above has been fixed, but here's another equally confusing variant: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite([TestStats]) unittest.TextTestRunner(verbosity=2).run(suite) giving: Traceback (most recent call last): File "test-foo.py", line 8, in ? unittest.TextTestRunner(verbosity=2).run(suite) File "/home/johannes/python/Lib/unittest.py", line 695, in run test(result) File "/home/johannes/python/Lib/unittest.py", line 426, in __call__ test(result) File "/home/johannes/python/Lib/unittest.py", line 396, in __init__ self.addTests(tests) File "/home/johannes/python/Lib/unittest.py", line 416, in addTests for test in tests: TypeError: iteration over non-sequence so I'm leaving this open. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 13:39 Message: Logged In: YES user_id=129426 patch is at #1061904 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470 From noreply at sourceforge.net Sun Dec 4 20:54:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 11:54:39 -0800 Subject: [ python-Bugs-1281032 ] xml.sax.expatreader doesn't pass encoding to ParserCreate Message-ID: Bugs item #1281032, was opened at 2005-09-02 18:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281032&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Samuel Bayer (sambayer) >Assigned to: A.M. Kuchling (akuchling) Summary: xml.sax.expatreader doesn't pass encoding to ParserCreate Initial Comment: The ParserCreate function in the expat module accepts an encoding argument, presumably for use when the encoding is not provided in the XML document. This function is invoked by the reset() method of the ExpatParser class in xml.sax.expatreader. The encoding, if provided, is available from the InputSource object stored in the self._source variable, but the value is not passed along to ParserCreate. This bug is present in Python 2.4.1. I believe the correct fix is to change lines 246 and 247 in Lib/xml/ sax/expatreader.py from self._parser = expat.ParserCreate(None, " ", intern=self._interning) to self._parser = expat.ParserCreate(self._source.getEncoding (), " ", intern=self._interning) and line 252 from self._parser = expat.ParserCreate(intern = self._interning) to self._parser = expat.ParserCreate(self._source.getEncoding (), intern = self._interning) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 14:54 Message: Logged In: YES user_id=11375 Suggested change applied to rev41597; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281032&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:01:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:01:13 -0800 Subject: [ python-Bugs-847665 ] XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Message-ID: Bugs item #847665, was opened at 2003-11-23 10:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Initial Comment: from xml.sax.saxutils import XMLGenerator g = XMLGenerator(encoding='utf8') STREAM_NAMESPACE = 'http://etherx.jabber.org/streams' CLIENT_NAMESPACE = 'jabber:client' g.startDocument() g.startPrefixMapping('stream', STREAM_NAMESPACE) g.startPrefixMapping('client', CLIENT_NAMESPACE) g.startElementNS( (STREAM_NAMESPACE, 'stream'), 'stream', {(None,'xmlns'): CLIENT_NAMESPACE} ) Dies with: Traceback (most recent call last): File "tst.py", line 11, in ? g.startElementNS( File "/System/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/xml/sax/saxutils.py", line 124, in startElementNS name = self._current_context[name[0]] + ":" + name[1] KeyError: 'x' Changing the end of XMLGenerator.startElementNS to the following makes it work the way I expect: for (name, value) in attrs.items(): if name[0] is None: name = name[1] else: name = self._current_context[name[0]] + ":" + name[1] self._out.write(' %s=%s' % (name, quoteattr(value))) self._out.write('>') ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 15:01 Message: Logged In: YES user_id=11375 I don't understand your second example; it uses saxutils to parse a file. What's it got to do with XMLGenerator? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-11-24 14:36 Message: Logged In: YES user_id=46639 This method also appears to have trouble emmitting tags without a namespace prefix: import xml.sax import xml.sax.handler import xml.sax.saxutils x = '''<?xml version="1.0"?><mechanisms xmlns='urn:ietf: params:xml:ns:xmpp-sasl' >''' parser = xml.sax.make_parser() parser.setFeature(xml.sax.handler.feature_namespaces, True) parser.setContentHandler(xml.sax.saxutils.XMLGenerator()) parser.feed(x) dies with: Traceback (most recent call last): File "tst.py", line 30, in ? parser.feed(x) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/expatreader.py", line 207, in feed self._parser.Parse(data, isFinal) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/expatreader.py", line 337, in start_element_ns AttributesNSImpl(newattrs, qnames)) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/saxutils.py", line 116, in startElementNS name = self._current_context[name[0]] + ":" + name[1] TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' I've attached my current replacement startElementNS method which appears to fix both this and the previous issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:02:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:02:34 -0800 Subject: [ python-Bugs-847665 ] XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Message-ID: Bugs item #847665, was opened at 2003-11-23 10:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Initial Comment: from xml.sax.saxutils import XMLGenerator g = XMLGenerator(encoding='utf8') STREAM_NAMESPACE = 'http://etherx.jabber.org/streams' CLIENT_NAMESPACE = 'jabber:client' g.startDocument() g.startPrefixMapping('stream', STREAM_NAMESPACE) g.startPrefixMapping('client', CLIENT_NAMESPACE) g.startElementNS( (STREAM_NAMESPACE, 'stream'), 'stream', {(None,'xmlns'): CLIENT_NAMESPACE} ) Dies with: Traceback (most recent call last): File "tst.py", line 11, in ? g.startElementNS( File "/System/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/xml/sax/saxutils.py", line 124, in startElementNS name = self._current_context[name[0]] + ":" + name[1] KeyError: 'x' Changing the end of XMLGenerator.startElementNS to the following makes it work the way I expect: for (name, value) in attrs.items(): if name[0] is None: name = name[1] else: name = self._current_context[name[0]] + ":" + name[1] self._out.write(' %s=%s' % (name, quoteattr(value))) self._out.write('>') ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 15:02 Message: Logged In: YES user_id=11375 Never mind my previous comment; I just noticed the setContentHandler call. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 15:01 Message: Logged In: YES user_id=11375 I don't understand your second example; it uses saxutils to parse a file. What's it got to do with XMLGenerator? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-11-24 14:36 Message: Logged In: YES user_id=46639 This method also appears to have trouble emmitting tags without a namespace prefix: import xml.sax import xml.sax.handler import xml.sax.saxutils x = '''<?xml version="1.0"?><mechanisms xmlns='urn:ietf: params:xml:ns:xmpp-sasl' >''' parser = xml.sax.make_parser() parser.setFeature(xml.sax.handler.feature_namespaces, True) parser.setContentHandler(xml.sax.saxutils.XMLGenerator()) parser.feed(x) dies with: Traceback (most recent call last): File "tst.py", line 30, in ? parser.feed(x) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/expatreader.py", line 207, in feed self._parser.Parse(data, isFinal) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/expatreader.py", line 337, in start_element_ns AttributesNSImpl(newattrs, qnames)) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/saxutils.py", line 116, in startElementNS name = self._current_context[name[0]] + ":" + name[1] TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' I've attached my current replacement startElementNS method which appears to fix both this and the previous issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:15:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:15:48 -0800 Subject: [ python-Bugs-847665 ] XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Message-ID: Bugs item #847665, was opened at 2003-11-23 10:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Initial Comment: from xml.sax.saxutils import XMLGenerator g = XMLGenerator(encoding='utf8') STREAM_NAMESPACE = 'http://etherx.jabber.org/streams' CLIENT_NAMESPACE = 'jabber:client' g.startDocument() g.startPrefixMapping('stream', STREAM_NAMESPACE) g.startPrefixMapping('client', CLIENT_NAMESPACE) g.startElementNS( (STREAM_NAMESPACE, 'stream'), 'stream', {(None,'xmlns'): CLIENT_NAMESPACE} ) Dies with: Traceback (most recent call last): File "tst.py", line 11, in ? g.startElementNS( File "/System/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/xml/sax/saxutils.py", line 124, in startElementNS name = self._current_context[name[0]] + ":" + name[1] KeyError: 'x' Changing the end of XMLGenerator.startElementNS to the following makes it work the way I expect: for (name, value) in attrs.items(): if name[0] is None: name = name[1] else: name = self._current_context[name[0]] + ":" + name[1] self._out.write(' %s=%s' % (name, quoteattr(value))) self._out.write('>') ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 15:15 Message: Logged In: YES user_id=11375 Please provide your changes in the form of a patch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 15:02 Message: Logged In: YES user_id=11375 Never mind my previous comment; I just noticed the setContentHandler call. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 15:01 Message: Logged In: YES user_id=11375 I don't understand your second example; it uses saxutils to parse a file. What's it got to do with XMLGenerator? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-11-24 14:36 Message: Logged In: YES user_id=46639 This method also appears to have trouble emmitting tags without a namespace prefix: import xml.sax import xml.sax.handler import xml.sax.saxutils x = '''<?xml version="1.0"?><mechanisms xmlns='urn:ietf: params:xml:ns:xmpp-sasl' >''' parser = xml.sax.make_parser() parser.setFeature(xml.sax.handler.feature_namespaces, True) parser.setContentHandler(xml.sax.saxutils.XMLGenerator()) parser.feed(x) dies with: Traceback (most recent call last): File "tst.py", line 30, in ? parser.feed(x) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/expatreader.py", line 207, in feed self._parser.Parse(data, isFinal) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/expatreader.py", line 337, in start_element_ns AttributesNSImpl(newattrs, qnames)) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/saxutils.py", line 116, in startElementNS name = self._current_context[name[0]] + ":" + name[1] TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' I've attached my current replacement startElementNS method which appears to fix both this and the previous issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:20:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:20:40 -0800 Subject: [ python-Bugs-1363104 ] spawnlp is missing Message-ID: Bugs item #1363104, was opened at 2005-11-21 16:16 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363104&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Greg MacDonald (gtm256) Assigned to: Nobody/Anonymous (nobody) Summary: spawnlp is missing Initial Comment: spawnlp is missing from my os module. I am running 2.4.2 on windows 2000. >>> dir(os) ['F_OK', 'O_APPEND', 'O_BINARY', 'O_CREAT', 'O_EXCL', ' O_NOINHERIT', 'O_RANDOM', 'O_RDONLY', 'O_RDWR', 'O_SEQU ENTIAL', 'O_SHORT_LIVED', 'O_TEMPORARY', 'O_TEXT', 'O_T RUNC', 'O_WRONLY', 'P_DETACH', 'P_NOWAIT', 'P_NOWAITO', 'P_OVERLAY', 'P_WAIT', 'R_OK', 'TMP_MAX', 'UserDict', 'W_OK', 'X_OK', '_Environ', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '_copy_reg', '_execv pe', '_exists', '_exit', '_get_exports_list', '_make_st at_result', '_make_statvfs_result', '_pickle_stat_resul t', '_pickle_statvfs_result', 'abort', 'access', 'altse p', 'chdir', 'chmod', 'close', 'curdir', 'defpath', 'de vnull', 'dup', 'dup2', 'environ', 'error', 'execl', 'ex ecle', 'execlp', 'execlpe', 'execv', 'execve', 'execvp' , 'execvpe', 'extsep', 'fdopen', 'fstat', 'fsync', 'get cwd', 'getcwdu', 'getenv', 'getpid', 'isatty', 'linesep ', 'listdir', 'lseek', 'lstat', 'makedirs', 'mkdir', 'n ame', 'open', 'pardir', 'path', 'pathsep', 'pipe', 'pop en', 'popen2', 'popen3', 'popen4', 'putenv', 'read', 'r emove', 'removedirs', 'rename', 'renames', 'rmdir', 'se p', 'spawnl', 'spawnle', 'spawnv', 'spawnve', 'startfil e', 'stat', 'stat_float_times', 'stat_result', 'statvfs _result', 'strerror', 'sys', 'system', 'tempnam', 'time s', 'tmpfile', 'tmpnam', 'umask', 'unlink', 'unsetenv', 'urandom', 'utime', 'waitpid', 'walk', 'write'] ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 15:20 Message: Logged In: YES user_id=11375 Not a bug: spawnlp and spawnvp are not available on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363104&group_id=5470 From noreply at sourceforge.net Sun Dec 4 23:46:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 14:46:44 -0800 Subject: [ python-Bugs-1372650 ] Cookie and multiple names Message-ID: Bugs item #1372650, was opened at 2005-12-03 18:47 Message generated for change (Comment added) made by valankar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. ---------------------------------------------------------------------- >Comment By: Viraj Alankar (valankar) Date: 2005-12-04 13:46 Message: Logged In: YES user_id=107970 Heh I guess that means I should try to write a patch. Might be a good learning experience for me. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 09:16 Message: Logged In: YES user_id=261020 OK, I see. I agree that it's a bug, but I'm undecided whether the existing behaviour should be fixed. It's true that clients are supposed to (and do) send the most specific cookie last, so this bug could cause servers to see the cookie from, eg path '/cgi-bin' instead of from path '/mystuff/cgi-bin'. However, module Cookie is old and stable, and a patch might break servers expecting the current behaviour. I *suppose* such breakage is fairly unlikely, so I wouldn't object to a patch. I certainly don't see anybody objecting to a patch to add a new method to allow access to multiple cookies of the same name without altering the existing dict interface (repr() could change, but not eg. .get()). Either way, I suspect a patch is only likely to appear from somebody who is actually using such cookies, though :-) ---------------------------------------------------------------------- Comment By: Viraj Alankar (valankar) Date: 2005-12-04 07:07 Message: Logged In: YES user_id=107970 Basically, sometimes a web client will send 2 instances of the same name: Cookie: mycookie=foo; mycookie=bar The specs say that the first one is the one that should be used. The other cookies listed are the inherited ones from paths that a prefix of the current URL. When this is parsed by the Cookie module, mycookie gets set to bar when it should be foo. Another example might be: Cookie: mycookie=foo; path=bar Cookie: mycookie=foo; path=baz In this case there should be 2 cookies with the name 'mycookie'. The uniqueness is determined by the different paths. Thanks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 06:52 Message: Logged In: YES user_id=261020 I don't get it: >>> import Cookie >>> c = Cookie.SimpleCookie() >>> c.load("foo=bar; bar=baz") >>> c Where's the problem? In general, don't pay too much attention to that standard, BTW: http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 From noreply at sourceforge.net Mon Dec 5 01:00:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 16:00:50 -0800 Subject: [ python-Bugs-1373150 ] diffs in working copy after a build Message-ID: Bugs item #1373150, was opened at 2005-12-05 00: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=1373150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: diffs in working copy after a build Initial Comment: I habitually build python in a subdirectory of the checkout directory (cd build; ../configure; make). After I do this, "svn diff" says this: Index: Include/Python-ast.h ============================================= ====================== --- Include/Python-ast.h (revision 41584) +++ Include/Python-ast.h (working copy) @@ -1,4 +1,4 @@ -/* File automatically generated by ./Parser/asdl_c.py */ +/* File automatically generated by ../Parser/asdl_c.py */ #include "asdl.h" Index: Python/Python-ast.c ============================================= ====================== --- Python/Python-ast.c (revision 41584) +++ Python/Python-ast.c (working copy) @@ -1,4 +1,4 @@ -/* File automatically generated by ./Parser/asdl_c.py */ +/* File automatically generated by ../Parser/asdl_c.py */ #include "Python.h" #include "Python-ast.h" which is kind of annoying. "File automatically generated by asdl_c.py" would probably do fine for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373150&group_id=5470 From noreply at sourceforge.net Mon Dec 5 01:25:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 16:25:31 -0800 Subject: [ python-Bugs-1373161 ] r41552 broke test_file on OS X Message-ID: Bugs item #1373161, was opened at 2005-12-05 00: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=1373161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Neal Norwitz (nnorwitz) Summary: r41552 broke test_file on OS X Initial Comment: Apparently you *can* seek on sys.stdin here. If you just want seek() to fail sys.stdin.seek(-1) seems pretty likely to work... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 From noreply at sourceforge.net Mon Dec 5 01:26:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 16:26:56 -0800 Subject: [ python-Bugs-1373150 ] diffs in working copy after a build Message-ID: Bugs item #1373150, was opened at 2005-12-04 16:00 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: diffs in working copy after a build Initial Comment: I habitually build python in a subdirectory of the checkout directory (cd build; ../configure; make). After I do this, "svn diff" says this: Index: Include/Python-ast.h ============================================= ====================== --- Include/Python-ast.h (revision 41584) +++ Include/Python-ast.h (working copy) @@ -1,4 +1,4 @@ -/* File automatically generated by ./Parser/asdl_c.py */ +/* File automatically generated by ../Parser/asdl_c.py */ #include "asdl.h" Index: Python/Python-ast.c ============================================= ====================== --- Python/Python-ast.c (revision 41584) +++ Python/Python-ast.c (working copy) @@ -1,4 +1,4 @@ -/* File automatically generated by ./Parser/asdl_c.py */ +/* File automatically generated by ../Parser/asdl_c.py */ #include "Python.h" #include "Python-ast.h" which is kind of annoying. "File automatically generated by asdl_c.py" would probably do fine for me. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-12-04 16:26 Message: Logged In: YES user_id=357491 Would changing the path to say /Parser/asdl_c.py work for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373150&group_id=5470 From noreply at sourceforge.net Mon Dec 5 01:32:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 16:32:02 -0800 Subject: [ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c Message-ID: Bugs item #1346144, was opened at 2005-11-02 17:07 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Rune Holm (titanstar) Assigned to: Michael Hudson (mwh) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737 return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0) at Python/ceval.c:3586 #9 0x0050710c in PyEval_EvalFrameEx (f=0x10034eb0, throw=0) at Python/ceval.c:2181 #10 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d38, globals=0x2b0cd4d0, locals=0x0, args=0x2b22820c, argcount=2, kws=0x2b2c5048, kwcount=0, defs=0x2b0e7b3c, defcount=1, closure=0x0) at Python/ceval.c: 2739 #11 0x005c3260 in function_call (func=0x2b0ee248, arg=0x2b2281f8, ---Type to continue, or q to quit--- kw=0x2b2c4578) at Objects/funcobject.c:550 #12 0x0041e8dc in PyObject_Call (func=0x2b0ee248, arg=0x2b2281f8, kw=0x2b2c4578) at Objects/abstract.c:1777 #13 0x005112b8 in ext_do_call (func=0x2b0ee248, pp_stack=0x7fff2aa8, flags=3, na=1, nk=0) at Python/ceval.c:3842 #14 0x00507534 in PyEval_EvalFrameEx (f=0x100347c8, throw=0) at Python/ceval.c:2221 #15 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d90, globals=0x2b0cd4d0, locals=0x0, args=0x2b22824c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2739 #16 0x005c3260 in function_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/funcobject.c:550 #17 0x0041e8dc in PyObject_Call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/abstract.c:1777 #18 0x00430b7c in instancemethod_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/classobject.c:2447 #19 0x0041e8dc in PyObject_Call (func=0x2b0aaf38, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #20 0x004b5c80 in slot_tp_call (self=0x2b1f5118, args=0x2b2c2b60, kwds=0x0) at Objects/typeobject.c:4530 #21 0x0041e8dc in PyObject_Call (func=0x2b1f5118, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #22 0x00510d08 in do_call (func=0x2b1f5118, pp_stack=0x7fff3460, na=1, nk=0) at Python/ceval.c:3773 ---Type to continue, or q to quit--- ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-05 00:32 Message: Logged In: YES user_id=6656 Uh, that was an embarrassing one, thanks for the catch :) Checked in as revision 41601. Thanks for the report too :) ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-26 18:00 Message: Logged In: YES user_id=858364 Your patch to _PyFloat_Unpack4 loaded a float into the first half of a double, but after I fixed it to load into a float, the test suite passed on x86, sparc64 and mips. The revised patch should be attached. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-11-23 12:51 Message: Logged In: YES user_id=6656 Well, this isn't soon, but here's a patch to try. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-11-03 10:33 Message: Logged In: YES user_id=6656 Uh, yeah, completely my fault -- don't know what I was thinking. Should be easy to fix, I'll have a patch for you soon. ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-02 17:38 Message: Logged In: YES user_id=858364 Some more digging reveals that the problem is caused by the patches from https://sourceforge.net/tracker/index.php? func=detail&aid=1181301&group_id=5470&atid=305470 and there is a similar problem in _PyFloat_Unpack4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 From noreply at sourceforge.net Mon Dec 5 01:32:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 16:32:23 -0800 Subject: [ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c Message-ID: Bugs item #1346144, was opened at 2005-11-02 17:07 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Rune Holm (titanstar) Assigned to: Michael Hudson (mwh) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737 return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0) at Python/ceval.c:3586 #9 0x0050710c in PyEval_EvalFrameEx (f=0x10034eb0, throw=0) at Python/ceval.c:2181 #10 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d38, globals=0x2b0cd4d0, locals=0x0, args=0x2b22820c, argcount=2, kws=0x2b2c5048, kwcount=0, defs=0x2b0e7b3c, defcount=1, closure=0x0) at Python/ceval.c: 2739 #11 0x005c3260 in function_call (func=0x2b0ee248, arg=0x2b2281f8, ---Type to continue, or q to quit--- kw=0x2b2c4578) at Objects/funcobject.c:550 #12 0x0041e8dc in PyObject_Call (func=0x2b0ee248, arg=0x2b2281f8, kw=0x2b2c4578) at Objects/abstract.c:1777 #13 0x005112b8 in ext_do_call (func=0x2b0ee248, pp_stack=0x7fff2aa8, flags=3, na=1, nk=0) at Python/ceval.c:3842 #14 0x00507534 in PyEval_EvalFrameEx (f=0x100347c8, throw=0) at Python/ceval.c:2221 #15 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d90, globals=0x2b0cd4d0, locals=0x0, args=0x2b22824c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2739 #16 0x005c3260 in function_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/funcobject.c:550 #17 0x0041e8dc in PyObject_Call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/abstract.c:1777 #18 0x00430b7c in instancemethod_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/classobject.c:2447 #19 0x0041e8dc in PyObject_Call (func=0x2b0aaf38, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #20 0x004b5c80 in slot_tp_call (self=0x2b1f5118, args=0x2b2c2b60, kwds=0x0) at Objects/typeobject.c:4530 #21 0x0041e8dc in PyObject_Call (func=0x2b1f5118, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #22 0x00510d08 in do_call (func=0x2b1f5118, pp_stack=0x7fff3460, na=1, nk=0) at Python/ceval.c:3773 ---Type to continue, or q to quit--- ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-05 00:32 Message: Logged In: YES user_id=6656 Uh, that was an embarrassing one, thanks for the catch :) Checked in as revision 41601. Thanks for the report too :) ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-26 18:00 Message: Logged In: YES user_id=858364 Your patch to _PyFloat_Unpack4 loaded a float into the first half of a double, but after I fixed it to load into a float, the test suite passed on x86, sparc64 and mips. The revised patch should be attached. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-11-23 12:51 Message: Logged In: YES user_id=6656 Well, this isn't soon, but here's a patch to try. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-11-03 10:33 Message: Logged In: YES user_id=6656 Uh, yeah, completely my fault -- don't know what I was thinking. Should be easy to fix, I'll have a patch for you soon. ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-02 17:38 Message: Logged In: YES user_id=858364 Some more digging reveals that the problem is caused by the patches from https://sourceforge.net/tracker/index.php? func=detail&aid=1181301&group_id=5470&atid=305470 and there is a similar problem in _PyFloat_Unpack4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 From noreply at sourceforge.net Mon Dec 5 02:17:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 17:17:32 -0800 Subject: [ python-Bugs-1373150 ] diffs in working copy after a build Message-ID: Bugs item #1373150, was opened at 2005-12-05 00:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: diffs in working copy after a build Initial Comment: I habitually build python in a subdirectory of the checkout directory (cd build; ../configure; make). After I do this, "svn diff" says this: Index: Include/Python-ast.h ============================================= ====================== --- Include/Python-ast.h (revision 41584) +++ Include/Python-ast.h (working copy) @@ -1,4 +1,4 @@ -/* File automatically generated by ./Parser/asdl_c.py */ +/* File automatically generated by ../Parser/asdl_c.py */ #include "asdl.h" Index: Python/Python-ast.c ============================================= ====================== --- Python/Python-ast.c (revision 41584) +++ Python/Python-ast.c (working copy) @@ -1,4 +1,4 @@ -/* File automatically generated by ./Parser/asdl_c.py */ +/* File automatically generated by ../Parser/asdl_c.py */ #include "Python.h" #include "Python-ast.h" which is kind of annoying. "File automatically generated by asdl_c.py" would probably do fine for me. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-05 01:17 Message: Logged In: YES user_id=6656 Yes, whatever gets rid of the Ms in my wc :) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-05 00:26 Message: Logged In: YES user_id=357491 Would changing the path to say /Parser/asdl_c.py work for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373150&group_id=5470 From noreply at sourceforge.net Mon Dec 5 02:17:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 17:17:43 -0800 Subject: [ python-Bugs-1373161 ] r41552 broke test_file on OS X Message-ID: Bugs item #1373161, was opened at 2005-12-04 16:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Neal Norwitz (nnorwitz) Summary: r41552 broke test_file on OS X Initial Comment: Apparently you *can* seek on sys.stdin here. If you just want seek() to fail sys.stdin.seek(-1) seems pretty likely to work... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-04 17:17 Message: Logged In: YES user_id=33168 revision 41602 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 From noreply at sourceforge.net Mon Dec 5 02:32:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 17:32:06 -0800 Subject: [ python-Bugs-1223238 ] race in os.makedirs() Message-ID: Bugs item #1223238, was opened at 2005-06-18 19:37 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-05 03:32 Message: Logged In: YES user_id=832344 I agree that raising an error for existing directories is usually not what you want, but changing this will break any code that count on that documented behavior. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-07-18 15:08 Message: Logged In: YES user_id=432579 Whether the dir creation is done right-to-left or left-to-right is less important. If the expected usage pattern is that most of the directories already exist, then right-to-left may be faster, otherwise left-to-right is. One advantage with the former is its slightly simpler code (no need to check for ENOENT). >current 2.4 code does not return an error if the directory exists, >the patch must not change that behavior. You mean the contrary? From what I can see of the 2.4 code, it throws an error if the directory exists. This is almost never what you want, so I strongly doubt fixing that misfeature in 2.5 would break anything. I'm happy with the suggested patch for 2.5 in #1239890. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-18 00:10 Message: Logged In: YES user_id=832344 current 2.4 code does not return an error if the directory exists, the patch must not change that behavior. It will not be a good idea to change that behavior in 2.5 or any version, it can break lot of code. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:56 Message: Logged In: YES user_id=1188172 See patch #1239890. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-06-26 00:11 Message: Logged In: YES user_id=432579 I'm fine with fixing the design for 2.5 and ignoring the bug for 2.4, since programs susceptible to the bug must use some kind of work-around in 2.4.x (x < 2) anyway. What I am using right now is: def makedirs(name, mode=0777): try: os.mkdir(name, mode) return except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT: raise makedirs(os.path.dirname(name), mode) makedirs(name, mode) This is compact and elegant, but relies on mkdir producing the correct errno values, which should be true for all platforms I'm aware of. It could also theoretically loop infinitely in bizarre cases but I don't see how that ever could happen. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 20:43 Message: Logged In: YES user_id=35752 I vote to fix the design for 2.5. Backporting the minimal fix to 2.4 would be optional, IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 From noreply at sourceforge.net Mon Dec 5 03:05:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 18:05:00 -0800 Subject: [ python-Bugs-1373197 ] os.makedirs fail if path contains os.pardir Message-ID: Bugs item #1373197, was opened at 2005-12-05 04:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs fail if path contains os.pardir Initial Comment: os.makedirs fail with "OSError: [Errno 17] File exists:" error when trying to create paths like 'a/b/../c' or 'a/b/c/..'. Seen on 2.3.0, 2.4.1 and 2.5.0. Included patch with new test cases that fail with current 2.5 code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373197&group_id=5470 From noreply at sourceforge.net Mon Dec 5 03:08:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 18:08:11 -0800 Subject: [ python-Bugs-1373197 ] os.makedirs fail if path contains os.pardir Message-ID: Bugs item #1373197, was opened at 2005-12-05 04:05 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs fail if path contains os.pardir Initial Comment: os.makedirs fail with "OSError: [Errno 17] File exists:" error when trying to create paths like 'a/b/../c' or 'a/b/c/..'. Seen on 2.3.0, 2.4.1 and 2.5.0. Included patch with new test cases that fail with current 2.5 code. ---------------------------------------------------------------------- >Comment By: Nir Soffer (nirs) Date: 2005-12-05 04:08 Message: Logged In: YES user_id=832344 And here are the tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373197&group_id=5470 From noreply at sourceforge.net Mon Dec 5 10:31:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 01:31:40 -0800 Subject: [ python-Bugs-1373161 ] r41552 broke test_file on OS X Message-ID: Bugs item #1373161, was opened at 2005-12-05 00:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Neal Norwitz (nnorwitz) Summary: r41552 broke test_file on OS X Initial Comment: Apparently you *can* seek on sys.stdin here. If you just want seek() to fail sys.stdin.seek(-1) seems pretty likely to work... ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-05 09:31 Message: Logged In: YES user_id=6656 I suspect you know this from what I said on IRC, but test_file still fails, because you can tell() on sys.stdin too (I don't really see what you can do about this) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-05 01:17 Message: Logged In: YES user_id=33168 revision 41602 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 From noreply at sourceforge.net Tue Dec 6 06:59:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 21:59:13 -0800 Subject: [ python-Bugs-1373161 ] r41552 broke test_file on OS X Message-ID: Bugs item #1373161, was opened at 2005-12-04 16:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Neal Norwitz (nnorwitz) Summary: r41552 broke test_file on OS X Initial Comment: Apparently you *can* seek on sys.stdin here. If you just want seek() to fail sys.stdin.seek(-1) seems pretty likely to work... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-05 21:59 Message: Logged In: YES user_id=33168 Sorry, I think I closed the report before I saw that there was another problem. From a man page, it looked like tell() may fail if it is done on a pipe. So maybe the problem can't happen on OS X? We could check if the system is osx/darwin and skip the test. Do you want to skip the test? Since it was for coverage and to ensure nothing bad goes wrong with error handling, it's not awful that it can't be provoked on osx. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-05 01:31 Message: Logged In: YES user_id=6656 I suspect you know this from what I said on IRC, but test_file still fails, because you can tell() on sys.stdin too (I don't really see what you can do about this) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-04 17:17 Message: Logged In: YES user_id=33168 revision 41602 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 From noreply at sourceforge.net Tue Dec 6 21:21:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 12:21:07 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-12-06 12:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 09:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 18:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 12:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 20:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 14:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 05:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 11:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 04:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Tue Dec 6 21:40:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 12:40:36 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 18:08 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 14:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 14:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 11:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 20:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 14:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 22:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 15:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 16:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 07:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 13:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 06:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 12:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 10:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Tue Dec 6 22:21:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 13:21:29 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-12-06 13:21 Message: Logged In: YES user_id=131838 Then file a bug report with whoever makes your web browser. It's not Python's webbrowser module's fault that the browser doesn't accept filesystem paths. The webbrowser module is only documented to work with URLs, so any code that depends on paths is arguably buggy. That said, if someone else will write a patch for the documentation, I will write a patch for the code. - Greg ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 12:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 12:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 09:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 18:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 12:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 20:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 14:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 05:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 11:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 04:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Tue Dec 6 22:58:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 13:58:00 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 18:08 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 15:57 Message: Logged In: YES user_id=44345 You're missing the point. It works in Python 2.4 and doesn't on CVS HEAD. I've already had to modify one application. Maybe the old webbrowser module used to prepend a "file://localhost/" to filenames that were missing schemes. All I know is it used to work and now it doesn't As is, 2.5 is likely to break some applications that rely on the behavior in 2.4. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 15:21 Message: Logged In: YES user_id=131838 Then file a bug report with whoever makes your web browser. It's not Python's webbrowser module's fault that the browser doesn't accept filesystem paths. The webbrowser module is only documented to work with URLs, so any code that depends on paths is arguably buggy. That said, if someone else will write a patch for the documentation, I will write a patch for the code. - Greg ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 14:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 14:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 11:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 20:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 14:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 22:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 15:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 16:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 07:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 13:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 06:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 12:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 10:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Tue Dec 6 23:27:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 14:27:50 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-12-06 14:27 Message: Logged In: YES user_id=131838 And you seem to have scanned my previous post and missed where I discussed all of the problems with webbrowser.open(path). I should have been more explicit that those were problems with the all versions of the webbrowser module. It is browser-dependent whether or not opening a path works at all. I have had to work around that "problem" for years (starting with grail in 1997 and carried over to the webbroswer module in 2001). Any cross-platform developer, that tests their code, already has a workaround in place. If the webbrowser documentation agreed with you, then I would agree with you as well. Although I feel we are already violently agreeing. "Fix" the documentation and I'll "fix" the code. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 13:57 Message: Logged In: YES user_id=44345 You're missing the point. It works in Python 2.4 and doesn't on CVS HEAD. I've already had to modify one application. Maybe the old webbrowser module used to prepend a "file://localhost/" to filenames that were missing schemes. All I know is it used to work and now it doesn't As is, 2.5 is likely to break some applications that rely on the behavior in 2.4. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 13:21 Message: Logged In: YES user_id=131838 Then file a bug report with whoever makes your web browser. It's not Python's webbrowser module's fault that the browser doesn't accept filesystem paths. The webbrowser module is only documented to work with URLs, so any code that depends on paths is arguably buggy. That said, if someone else will write a patch for the documentation, I will write a patch for the code. - Greg ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 12:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 12:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 09:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 18:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 12:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 20:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 14:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 05:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 11:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 04:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Wed Dec 7 00:38:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 15:38:11 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 18:08 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 17:38 Message: Logged In: YES user_id=44345 All I'm saying is that if this form webbrowser.open("/tmp/foo.html") was supported in Python 2.4, possibly by recognizing the bare path and silently pretending the programmer wrote webbrowser.open("file://localhost/tmp/foo.html") then it ought to do the same in 2.5 unless you intend to break existing applications. How hard can it be to recognize that the first character of the "url" is "/" and prepend "file://localhost/" before passing it along to the user's chosen browser? I suggest compatibility with urllib.urlopen is desirable: >>> f = urllib.urlopen("/etc/hosts") >>> f.read() "##\n# Host Database\n# \n# Note that this file is consulted when the system is running in single-user\n# mode. At other times this information is handled by lookupd. By default,\n# lookupd gets information from NetInfo, so this file will not be consulted\n# unless you have changed lookupd's configuration.\n#\n# localhost is used to configure the loopback interface\n# when the system is booting. Do not change this entry.\n##\n127.0.0.1\tlocalhost montanaro.dyndns.org\n255.255.255.255\tbroadcasthost\n" Skip ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 16:27 Message: Logged In: YES user_id=131838 And you seem to have scanned my previous post and missed where I discussed all of the problems with webbrowser.open(path). I should have been more explicit that those were problems with the all versions of the webbrowser module. It is browser-dependent whether or not opening a path works at all. I have had to work around that "problem" for years (starting with grail in 1997 and carried over to the webbroswer module in 2001). Any cross-platform developer, that tests their code, already has a workaround in place. If the webbrowser documentation agreed with you, then I would agree with you as well. Although I feel we are already violently agreeing. "Fix" the documentation and I'll "fix" the code. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 15:57 Message: Logged In: YES user_id=44345 You're missing the point. It works in Python 2.4 and doesn't on CVS HEAD. I've already had to modify one application. Maybe the old webbrowser module used to prepend a "file://localhost/" to filenames that were missing schemes. All I know is it used to work and now it doesn't As is, 2.5 is likely to break some applications that rely on the behavior in 2.4. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 15:21 Message: Logged In: YES user_id=131838 Then file a bug report with whoever makes your web browser. It's not Python's webbrowser module's fault that the browser doesn't accept filesystem paths. The webbrowser module is only documented to work with URLs, so any code that depends on paths is arguably buggy. That said, if someone else will write a patch for the documentation, I will write a patch for the code. - Greg ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 14:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 14:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 11:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 20:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 14:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 22:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 15:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 16:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 07:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 13:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 06:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 12:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 10:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Wed Dec 7 01:13:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 16:13:16 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-12-06 16:13 Message: Logged In: YES user_id=131838 And I agree it is desirable, but it didn't work reliably in 2.4 nor any earlier version, and it isn't documented to work. The urllib.urlopen example you gave fails miserably with Windows files names, i.e., given "C:\WINDOWS\system.ini" it tries to interpret the C as a scheme. You need to use urllib's pathname2url function and pass the result to urlopen. If webbrowser.open is fixed, then maybe there will be some pressure to fix urlopen as well. You just have been lucky or unlucky depending on how you view it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 15:38 Message: Logged In: YES user_id=44345 All I'm saying is that if this form webbrowser.open("/tmp/foo.html") was supported in Python 2.4, possibly by recognizing the bare path and silently pretending the programmer wrote webbrowser.open("file://localhost/tmp/foo.html") then it ought to do the same in 2.5 unless you intend to break existing applications. How hard can it be to recognize that the first character of the "url" is "/" and prepend "file://localhost/" before passing it along to the user's chosen browser? I suggest compatibility with urllib.urlopen is desirable: >>> f = urllib.urlopen("/etc/hosts") >>> f.read() "##\n# Host Database\n# \n# Note that this file is consulted when the system is running in single-user\n# mode. At other times this information is handled by lookupd. By default,\n# lookupd gets information from NetInfo, so this file will not be consulted\n# unless you have changed lookupd's configuration.\n#\n# localhost is used to configure the loopback interface\n# when the system is booting. Do not change this entry.\n##\n127.0.0.1\tlocalhost montanaro.dyndns.org\n255.255.255.255\tbroadcasthost\n" Skip ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 14:27 Message: Logged In: YES user_id=131838 And you seem to have scanned my previous post and missed where I discussed all of the problems with webbrowser.open(path). I should have been more explicit that those were problems with the all versions of the webbrowser module. It is browser-dependent whether or not opening a path works at all. I have had to work around that "problem" for years (starting with grail in 1997 and carried over to the webbroswer module in 2001). Any cross-platform developer, that tests their code, already has a workaround in place. If the webbrowser documentation agreed with you, then I would agree with you as well. Although I feel we are already violently agreeing. "Fix" the documentation and I'll "fix" the code. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 13:57 Message: Logged In: YES user_id=44345 You're missing the point. It works in Python 2.4 and doesn't on CVS HEAD. I've already had to modify one application. Maybe the old webbrowser module used to prepend a "file://localhost/" to filenames that were missing schemes. All I know is it used to work and now it doesn't As is, 2.5 is likely to break some applications that rely on the behavior in 2.4. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 13:21 Message: Logged In: YES user_id=131838 Then file a bug report with whoever makes your web browser. It's not Python's webbrowser module's fault that the browser doesn't accept filesystem paths. The webbrowser module is only documented to work with URLs, so any code that depends on paths is arguably buggy. That said, if someone else will write a patch for the documentation, I will write a patch for the code. - Greg ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 12:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 12:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 09:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 18:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 12:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 20:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 14:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 05:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 11:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 04:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Wed Dec 7 13:32:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Dec 2005 04:32:39 -0800 Subject: [ python-Bugs-1375258 ] Collapse distutils docs Message-ID: Bugs item #1375258, was opened at 2005-12-07 06: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=1375258&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Trash Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Collapse distutils docs Initial Comment: The global module index is huge, 358 entries by my quick check. 46 of those entries are related to distutils. Let collapse it a bit. The Carbon entries are also numerous, but not that bad. As an example, check the docs for the distutils.debug module: 11.16 distutils.debug -- Distutils debug mode This module provides the DEBUG flag. Except for the header and footer generated by latex2html, that's the entire thing! Doesn't seem like it deserves its own entry in the global module index... I'll try to get to this, but in case I don't, at least it's recorded here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375258&group_id=5470 From noreply at sourceforge.net Wed Dec 7 19:55:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Dec 2005 10:55:35 -0800 Subject: [ python-Bugs-1375599 ] Tutorial errors Message-ID: Bugs item #1375599, was opened at 2005-12-07 10: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=1375599&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Glen Kaukola (gkaukola) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial errors Initial Comment: In section 1 of the tutorial, it says this: "Python enables programs to written compactly and readably." It should probably read like so: "Python enables programs to be written compactly and readably." I'd like it even better like so: "Python enables programs to be compact and readable." Also, even though it probably doesn't matter really since it's just an example, in your Fibonacci sequence example in section 4.6 it should probably be "while b <= n" as opposed to "while b < n". Because if n == 1, nothing is spit out. But even then it still wouldn't handle 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375599&group_id=5470 From noreply at sourceforge.net Thu Dec 8 07:05:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Dec 2005 22:05:09 -0800 Subject: [ python-Bugs-1375599 ] Tutorial errors Message-ID: Bugs item #1375599, was opened at 2005-12-07 10:55 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375599&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Glen Kaukola (gkaukola) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial errors Initial Comment: In section 1 of the tutorial, it says this: "Python enables programs to written compactly and readably." It should probably read like so: "Python enables programs to be written compactly and readably." I'd like it even better like so: "Python enables programs to be compact and readable." Also, even though it probably doesn't matter really since it's just an example, in your Fibonacci sequence example in section 4.6 it should probably be "while b <= n" as opposed to "while b < n". Because if n == 1, nothing is spit out. But even then it still wouldn't handle 0. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-07 22:05 Message: Logged In: YES user_id=33168 Not sure where you are seeing the grammar problem in section 1. It is fixed in SVN and on this page: http://docs.python.org/tut/tut.html Presumably you are looking at an old version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375599&group_id=5470 From noreply at sourceforge.net Thu Dec 8 10:33:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 01:33:15 -0800 Subject: [ python-Bugs-857909 ] bsddb craps out sporadically Message-ID: Bugs item #857909, was opened at 2003-12-10 14:41 Message generated for change (Comment added) made by brandonh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Gregory P. Smith (greg) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; ------------------------ Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored ---------------------------------- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. ---------------------------------------------------------------------- Comment By: Brandon Hechinger (brandonh) Date: 2005-12-08 01:33 Message: Logged In: YES user_id=226421 We also get this error, though not using Python, but C. I'm not sure why people are so eager to dismiss it as an issue here, however, for it might be something your Python is doing with the Berkeley DB interface which could be improved. In our case, there is a similarity -- the site accesses the database(s) at relatively high frequency, and we use our own locking system to prevent any conflict (allowing multiple readers and exclusive writers -- writers not so much as generating a path to the database, let alone opening it, until they obtain the separate lock handled by our software). Periodically one of the databases will have an error when reading a key, and this error will remain until the database is repaired. The error return code is -30987. It's not 100% conclusive if it happens primarily on frequently accessed databases or not, and were it the case, it is not clear whether that's just because it occurs because of the high volume of access, or just because their volume increases the likelihood of encountering an error. In any case, our locking mechanisms (we've tried more than one) do lock prior to the database being opened at all, and are handled in a multi-reader single-writer way. Again, it's not clear if it's a Berkeley DB problem, or a problem with the *way* we are accessing/using Berkeley DB. Until this is known, I don't think it should be so quickly blown off that it's not a Python issue -- even if a bit of resources of the Python resources went into finding a Berkeley DB problem, would it result in such a bad world? :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-16 15:50 Message: Logged In: YES user_id=413 DB_RUNRECOVERY errors are a sleepycat BerkeleyDB internal error and don't have anything to do with the python library wrapper. For help in tracking them down I suggest using the latest BerkeleyDB version and ask with example code on the berkeleydb newsgroups or ask sleepycat themselves (they don't bite, they're friendly). closing this bug as its not a python or extension module bug. If you're looking for a multiprocess aware BerkeleyDB shelve support, that should be a feature request (ideally with an example implementation :). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-22 16:04 Message: Logged In: YES user_id=250749 I can sympathise with your POV, but shelve has a documented restriction that it is not supported for multiuser user use without specific external support - that is multiple readers are Ok, but writing requires exclusive access to the shelve database. As you are using it in such an environment, it is up to you to guarantee the required safety. The error being reported is highly likely to be a consequence of your locking scheme being inadequate for use with the BerkeleyDB environment, at least on that system, and my suggestion that you take this up in a BerkeleyDB forum was directed at you getting sufficient information to improve your locking scheme to avoid the problem you see. I think you are a little optimistic expecting the shelve module (let alone the anydbm module) to cope with exceptions arising from use outside its documented restrictions - and BerkeleyDB supports lots of capability beyond the scope of the functionality used by shelve and anydbm and the exceptions to go with that. If you care about the shelve storage format, you can force the type of storage by creating an empty database of the format of your choice, provided that that format is supported by anydbm. With a bit of care, you should be able to convert a shelve from one format to another, within the anydbm format support restriction. While it might be nice to have some format control, anydbm's purpose is hide the database format/interface. If you care about the format, you're expected to use the desired interface module directly. ---------------------------------------------------------------------- Comment By: Predrag Miocinovic (predragm) Date: 2003-12-21 20:48 Message: Logged In: YES user_id=860222 I find the last comment somewhat unsatisfactory. While this appears to be BerkeleyDB issue (and w/o going into details why the exception gets thrown), it's strange that Shelve module doesn't handle this more gracefully. Since the concept of Shelve is hiding implementation details from the application, having to catch BerkeleyDB exceptions for simple shelf operations is bit over the top. If I move to another system, using different underlying DB (as given by anydbm), will I have to catch new set of exceptions all over again? Shelve (or anydbm) should either provide ability to select underlying DB implementation to use, or it should handle all DB implementation aspects so that it is trully transparent to the end user. Just my $0.02. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-21 03:50 Message: Logged In: YES user_id=250749 As far as I can make out, what you're seeing is a BerkeleyDB issue, and bsddb is just reporting what BDB is telling it. DB_RUNRECOVERY (-30987 on DB 3.3, -30981 on DB 4.0) is documented as (quoted from DB4.0 HTML docs): "There exists a class of errors that Berkeley DB considers fatal to an entire Berkeley DB environment. An example of this type of error is a corrupted database or a log write failure because the disk is out of free space. The only way to recover from these failures is to have all threads of control exit the Berkeley DB environment, run recovery of the environment, and re-enter Berkeley DB." Therefore I think you should to followup this in a BerkeleyDB forum. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 From noreply at sourceforge.net Thu Dec 8 13:49:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 04:49:49 -0800 Subject: [ python-Bugs-1163563 ] Sub threads execute in restricted mode Message-ID: Bugs item #1163563, was opened at 2005-03-15 03:56 Message generated for change (Comment added) made by alephant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Michael Hudson (mwh) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done ---------------------------------------------------------------------- Comment By: Christopher DeMarco (alephant) Date: 2005-12-08 07:49 Message: Logged In: YES user_id=1400247 This is apparantly fixed in 2.4.2 despite the absence of an entry in the NEWS for that release. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-20 12:54 Message: Logged In: YES user_id=6656 Fixed, in Misc/NEWS revision 1.1301 Modules/threadmodule.c revision 2.64 Python/pystate.c revision 2.42 (I made a tiny tweak in addition to the latest patch attached to this report). yetanothermax: Thanks for the report, and the testing of patches! ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-17 10:37 Message: Logged In: YES user_id=1218811 The maybe-even-better-1010677-fix also seems to work ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-17 08:10 Message: Logged In: YES user_id=6656 That's good to hear. Tim: could you glance over the attached? If you can't be assed to read all the various reports, I've attempted to summarise the problem(s) here: http://mail.python.org/pipermail/python-dev/2005-June/054258.html If you don't have time, please at least say so... yetanothermax: thanks for the confirmation. Could you also try this cleaner version of the patch? Wrt your patch, it took me too long to work out that it was simply unapplying the earlier changes -- and you don't need to supply a patch for that, even creaky old CVS makes *that* easy :) ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-17 06:35 Message: Logged In: YES user_id=1218811 Good news - I've made a couple of tests and the patch seems to fix the problem. With regards to the earlier patch: - apologies for not running the test suite - I feel suitably chastised :) & I'll be sure to run it in the future. - I did note that it would probably re-raise #1010677 (see 2005-04-20 13:51 comment) but guessed it was more important to contribute the patch so that someone who has better thread implementation knowledge could look into it... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 08:39 Message: Logged In: YES user_id=6656 So here's my take on a fix to 1010677, relative to CVS HEAD. It's something of a hack, and I certainly wouldn't condone applying it to the trunk as is but I would be interested in hearing if it fixes your problems. (after applying your patch the test suite failed to complete, btw -- please try this yourself next time :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 08:09 Message: Logged In: YES user_id=6656 (Grr, SF hates me today) Why, are you under the impression that that could make a difference here? (hint: it can't). The problem with Py_NewInterpreter was an over-zealous check in PythreadState_Swap(), which I've tweaked. A red herring. On to the real problem... I see the problem, and can now reproduce it with your test code, but isn't your patch just a reversion of the patch that was attached to bug #1010677? Why won't applying it bring that patch back? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-06-16 07:32 Message: Logged In: YES user_id=1218811 Have you tried the threadtest.c with a debug build after applying the patch to threadmodule.c? The patch is here http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 Cheers, Max ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-16 05:58 Message: Logged In: YES user_id=6656 Hmm. threadtest.c just crashed for me with a debug build: Fatal Python error: Invalid thread state for this thread Abort trap This is in the call to Py_NewInterpreter() ... (eek). ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-17 04:49 Message: Logged In: YES user_id=1218811 I've created a patch for threadmodule.c http://sourceforge.net/tracker/index.php? func=detail&aid=1203393&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 04:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-12 03:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-05-12 03:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-21 08:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. ---------------------------------------------------------------------- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 01:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-04-20 23:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 07:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 07:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 ---------------------------------------------------------------------- Comment By: anothermax (yetanothermax) Date: 2005-04-20 07:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it uses the PyGILState_XXX constructs t_bootstrap() function. These do not seem to be compatible with running sub interpreters as JEP (and probably mod_python) do. The python documentation (http://docs.python.org/api/threads.html) says "Note that the PyGILState_*() functions assume there is only one global interpreter (created automatically by Py_Initialize()). Python still supports the creation of additional interpreters (using Py_NewInterpreter()), but mixing multiple interpreters and the PyGILState_*() API is unsupported. " I've compiled a new versions of the python2X.dll for both 2.3.5 and 2.4.1 changing the use of these PyGIL_StateXXX constructs back to the 2.3.4 form and this seems to resolve the problem (I've attached the updated threadmodule.c files for both 2.3.5 and 2.4.1). ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2005-04-16 16:27 Message: Logged In: YES user_id=282299 This problem also occurs on Linux. Note however that I've traced the source of the symptom to a different bug fix, namely [1010677] thread Module Breaks PyGILState_Ensure() (http://sourceforge.net/tracker/index.php?func=detail&aid=1010677&group_id=5470&atid=305470). Specifically, the change from v2.56 to v2.56.8.1 of threadmodule.c. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-16 15:21 Message: Logged In: YES user_id=357491 To answer the comment on bug #754449 and the email I got from someone, there is no way my fix for that bug would cause this. I only touched the 'threading' module, nothing else. That is in pure Python and thus has no direct way of modifying what does and does not execute in restricted mode. If I understand how restricted execution works that is all set at the C level. Plus the fix only deals with the teardown code; it in no way interfaces with how threads are executed. All changed code come after the thread and completed execution. The only thing it does ahead of time is store a reference to stdout. In other words it ain't my fault to the best of my knowledge. =) ---------------------------------------------------------------------- Comment By: Alan Davies (goatpunch) Date: 2005-03-31 01:24 Message: Logged In: YES user_id=967140 The same problem definately does occur with mod_python, I've found it to occur with Python 2.3.5 and 2.4 on Win32: http://www.modpython.org/pipermail/mod_python/2005- March/017802.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 From noreply at sourceforge.net Thu Dec 8 14:36:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 05:36:01 -0800 Subject: [ python-Bugs-857909 ] bsddb craps out sporadically Message-ID: Bugs item #857909, was opened at 2003-12-10 16:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Gregory P. Smith (greg) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; ------------------------ Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored ---------------------------------- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-08 07:36 Message: Logged In: YES user_id=44345 > We also get this error, though not using Python, but C. > I'm not sure why people are so eager to dismiss it as an > issue here, however, for it might be something your Python > is doing with the Berkeley DB interface which could be > improved. The anydbm module was written long before Berkeley DB supported any sort of adequate locking mechanisms (in the BDB 1.85 days). It also supports multiple backends (dbm and gdbm in particular). The API it present to the user is of little more than a dictionary that happens to be stored on-disk. To change its API at this point to use bsddb's (and underlying it, BDB's) locking mechanisms is impossible, as neither of the other underlying db backends supports locking. The right thing for the author to do in this case is probably to use the new bsddb module directly and take advantage of its locking features. The shelve module's functionality would be trivial to implement on top of that. All it really does is transparently pickle the data written to the disk. ---------------------------------------------------------------------- Comment By: Brandon Hechinger (brandonh) Date: 2005-12-08 03:33 Message: Logged In: YES user_id=226421 We also get this error, though not using Python, but C. I'm not sure why people are so eager to dismiss it as an issue here, however, for it might be something your Python is doing with the Berkeley DB interface which could be improved. In our case, there is a similarity -- the site accesses the database(s) at relatively high frequency, and we use our own locking system to prevent any conflict (allowing multiple readers and exclusive writers -- writers not so much as generating a path to the database, let alone opening it, until they obtain the separate lock handled by our software). Periodically one of the databases will have an error when reading a key, and this error will remain until the database is repaired. The error return code is -30987. It's not 100% conclusive if it happens primarily on frequently accessed databases or not, and were it the case, it is not clear whether that's just because it occurs because of the high volume of access, or just because their volume increases the likelihood of encountering an error. In any case, our locking mechanisms (we've tried more than one) do lock prior to the database being opened at all, and are handled in a multi-reader single-writer way. Again, it's not clear if it's a Berkeley DB problem, or a problem with the *way* we are accessing/using Berkeley DB. Until this is known, I don't think it should be so quickly blown off that it's not a Python issue -- even if a bit of resources of the Python resources went into finding a Berkeley DB problem, would it result in such a bad world? :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-16 17:50 Message: Logged In: YES user_id=413 DB_RUNRECOVERY errors are a sleepycat BerkeleyDB internal error and don't have anything to do with the python library wrapper. For help in tracking them down I suggest using the latest BerkeleyDB version and ask with example code on the berkeleydb newsgroups or ask sleepycat themselves (they don't bite, they're friendly). closing this bug as its not a python or extension module bug. If you're looking for a multiprocess aware BerkeleyDB shelve support, that should be a feature request (ideally with an example implementation :). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-22 18:04 Message: Logged In: YES user_id=250749 I can sympathise with your POV, but shelve has a documented restriction that it is not supported for multiuser user use without specific external support - that is multiple readers are Ok, but writing requires exclusive access to the shelve database. As you are using it in such an environment, it is up to you to guarantee the required safety. The error being reported is highly likely to be a consequence of your locking scheme being inadequate for use with the BerkeleyDB environment, at least on that system, and my suggestion that you take this up in a BerkeleyDB forum was directed at you getting sufficient information to improve your locking scheme to avoid the problem you see. I think you are a little optimistic expecting the shelve module (let alone the anydbm module) to cope with exceptions arising from use outside its documented restrictions - and BerkeleyDB supports lots of capability beyond the scope of the functionality used by shelve and anydbm and the exceptions to go with that. If you care about the shelve storage format, you can force the type of storage by creating an empty database of the format of your choice, provided that that format is supported by anydbm. With a bit of care, you should be able to convert a shelve from one format to another, within the anydbm format support restriction. While it might be nice to have some format control, anydbm's purpose is hide the database format/interface. If you care about the format, you're expected to use the desired interface module directly. ---------------------------------------------------------------------- Comment By: Predrag Miocinovic (predragm) Date: 2003-12-21 22:48 Message: Logged In: YES user_id=860222 I find the last comment somewhat unsatisfactory. While this appears to be BerkeleyDB issue (and w/o going into details why the exception gets thrown), it's strange that Shelve module doesn't handle this more gracefully. Since the concept of Shelve is hiding implementation details from the application, having to catch BerkeleyDB exceptions for simple shelf operations is bit over the top. If I move to another system, using different underlying DB (as given by anydbm), will I have to catch new set of exceptions all over again? Shelve (or anydbm) should either provide ability to select underlying DB implementation to use, or it should handle all DB implementation aspects so that it is trully transparent to the end user. Just my $0.02. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-21 05:50 Message: Logged In: YES user_id=250749 As far as I can make out, what you're seeing is a BerkeleyDB issue, and bsddb is just reporting what BDB is telling it. DB_RUNRECOVERY (-30987 on DB 3.3, -30981 on DB 4.0) is documented as (quoted from DB4.0 HTML docs): "There exists a class of errors that Berkeley DB considers fatal to an entire Berkeley DB environment. An example of this type of error is a corrupted database or a log write failure because the disk is out of free space. The only way to recover from these failures is to have all threads of control exit the Berkeley DB environment, run recovery of the environment, and re-enter Berkeley DB." Therefore I think you should to followup this in a BerkeleyDB forum. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 From noreply at sourceforge.net Thu Dec 8 14:46:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 05:46:07 -0800 Subject: [ python-Feature Requests-816628 ] request for bugs.python.org Message-ID: Feature Requests item #816628, was opened at 2003-10-02 11:55 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Philippe Fremy (pfremy) >Assigned to: A.M. Kuchling (akuchling) Summary: request for bugs.python.org Initial Comment: Many projects (gentoo, gnome, kde...) have the conveninent url for accessing the bug database: bugs.python.org That would be cool. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 08:46 Message: Logged In: YES user_id=11375 I don't know if Thomas looks at things in the Python bug tracker. I've written him directly, asking for bugs.python.org to be created, and will do the Apache tweaking once the name has been created. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-02 09:15 Message: Logged In: YES user_id=12800 I agree that this is a good idea, and easy to do. Let's add this hostname, point it at www.python.org, then set up an Apache rewrite rule to redirect to http://sourceforge.net/tracker/?group_id=5470&atid=105470 Assigning to Thomas for the dns tricks. I'll be happy to handle the Apache set up once the hostname has been added. ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2004-01-01 10:15 Message: Logged In: YES user_id=233844 The goal is not to duplicate the sf page, just to provide an easier way to find it. bugs.python.org is very convenient and easy to remember. It saves time for the people reporting bugs because one does not have to skim through the 100 links of www.python.org to find where to report bugs. Other projects have adpoted it with success. There is nothing to lose by providing this shortcut. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:39 Message: Logged In: YES user_id=80475 We now own the domain, but I don't see an advantage to duplicating what is on SF. The main website at www.python.org has a direct link on the main page. IMO, that is enough. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-10-02 12:15 Message: Logged In: YES user_id=12800 Even if it's a good idea, we can't do this until the PSF controls the python.org domain. I don't know what the status of that is, but I believe a transfer is in the works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 From noreply at sourceforge.net Thu Dec 8 14:55:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 05:55:37 -0800 Subject: [ python-Feature Requests-1376292 ] Write user's version of RefGuide Message-ID: Feature Requests item #1376292, was opened at 2005-12-08 08:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1376292&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Write user's version of RefGuide Initial Comment: The Reference Guide is very detailed and difficult to read, but nothing else documents things like statements or special object methods. We should have a shorter, friendlier guide to the syntax and basic types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1376292&group_id=5470 From noreply at sourceforge.net Thu Dec 8 15:35:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 06:35:13 -0800 Subject: [ python-Bugs-1376309 ] subprocess.CalledProcessError uses errno incorrectly Message-ID: Bugs item #1376309, was opened at 2005-12-08 09:14 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.CalledProcessError uses errno incorrectly Initial Comment: I have some code which uses subprocess.check_call(), which is buried in other code that catches an OSError, and does different things depending on OSError.errno. Since subprocess.CalledProcessError overloads errno for its own return code values, this leads to confusing error messages. The return code is NOT an errno, and I do not think this field should be overloaded in this way. Additionally, since OSError exceptions generally have an errno attribute set, and exception-handling code expects this, I do not think that CalledProcessError should subclass from it. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-12-08 09:27 Message: Logged In: YES user_id=987664 Ugh, this was supposed to be a bug, not a patch. Is there anyway to change this or should I just resumbit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 From noreply at sourceforge.net Thu Dec 8 15:55:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 06:55:01 -0800 Subject: [ python-Bugs-1349316 ] xmlrpclib does not use http proxy Message-ID: Bugs item #1349316, was opened at 2005-11-05 21:07 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Beisley (greatred) Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib does not use http proxy Initial Comment: The xmlrpclib class ServerProxy does not seem to be able to make use of a HTTP proxy. This makes it unusable behind a firewall where the proxy is the only access to the destination server. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 09:55 Message: Logged In: YES user_id=11375 Documentation changed in rev. 41636. Thanks! (Closing this bug, on the assumption that there's nothing further to be done.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 13:16 Message: Logged In: YES user_id=11375 I have a documentation change ready to go; will check that in once I get permission. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 05:32 Message: Logged In: YES user_id=38376 To handle this, you can use a custom transport. Here's an example: http://lowlife.jp/nobonobo/wiki/xmlrpcwithproxy.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 From noreply at sourceforge.net Thu Dec 8 17:06:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 08:06:32 -0800 Subject: [ python-Bugs-1376400 ] test_struct crashed, py2.3.5, solaris 10 Message-ID: Bugs item #1376400, was opened at 2005-12-08 17: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=1376400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: rrogans (rrogans) Assigned to: Nobody/Anonymous (nobody) Summary: test_struct crashed, py2.3.5, solaris 10 Initial Comment: Hi, I am building python 2.3.5 on solaris 10 using gcc 3.3.2. Run I perform the test I get one test failure - test_struct crashes. Rgds, Richard >>>>>>>>>>>> trying std qQ on 1471797217424382203 == 0x146CDFC575FD18FBL trying std qQ on 1471797217424382204 == 0x146CDFC575FD18FCL trying std qQ on 1471797217424382205 == 0x146CDFC575FD18FDL test test_struct crashed -- exceptions.OverflowError: math range error Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals (), []) File "/home/richardr/app/Python- 2.3.5/Lib/test/test_struct.py", line 439, in ? test_705836() File "/home/richardr/app/Python- 2.3.5/Lib/test/test_struct.py", line 424, in test_705836 big = math.ldexp(big, 127 - 23) OverflowError: math range error 1 test failed: test_struct <<<<<<<<<<< ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470 From noreply at sourceforge.net Thu Dec 8 18:31:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 09:31:53 -0800 Subject: [ python-Bugs-857909 ] bsddb craps out sporadically Message-ID: Bugs item #857909, was opened at 2003-12-10 14:41 Message generated for change (Comment added) made by brandonh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Gregory P. Smith (greg) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; ------------------------ Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored ---------------------------------- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. ---------------------------------------------------------------------- Comment By: Brandon Hechinger (brandonh) Date: 2005-12-08 09:31 Message: Logged In: YES user_id=226421 We also get this error, though not using Python, but C. I'm not sure why people are so eager to dismiss it as an issue here, however, for it might be something your Python is doing with the Berkeley DB interface which could be improved. In our case, there is a similarity -- the site accesses the database(s) at relatively high frequency, and we use our own locking system to prevent any conflict (allowing multiple readers and exclusive writers -- writers not so much as generating a path to the database, let alone opening it, until they obtain the separate lock handled by our software). Periodically one of the databases will have an error when reading a key, and this error will remain until the database is repaired. The error return code is -30987. It's not 100% conclusive if it happens primarily on frequently accessed databases or not, and were it the case, it is not clear whether that's just because it occurs because of the high volume of access, or just because their volume increases the likelihood of encountering an error. In any case, our locking mechanisms (we've tried more than one) do lock prior to the database being opened at all, and are handled in a multi-reader single-writer way. Again, it's not clear if it's a Berkeley DB problem, or a problem with the *way* we are accessing/using Berkeley DB. Until this is known, I don't think it should be so quickly blown off that it's not a Python issue -- even if a bit of resources of the Python resources went into finding a Berkeley DB problem, would it result in such a bad world? :) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-08 05:36 Message: Logged In: YES user_id=44345 > We also get this error, though not using Python, but C. > I'm not sure why people are so eager to dismiss it as an > issue here, however, for it might be something your Python > is doing with the Berkeley DB interface which could be > improved. The anydbm module was written long before Berkeley DB supported any sort of adequate locking mechanisms (in the BDB 1.85 days). It also supports multiple backends (dbm and gdbm in particular). The API it present to the user is of little more than a dictionary that happens to be stored on-disk. To change its API at this point to use bsddb's (and underlying it, BDB's) locking mechanisms is impossible, as neither of the other underlying db backends supports locking. The right thing for the author to do in this case is probably to use the new bsddb module directly and take advantage of its locking features. The shelve module's functionality would be trivial to implement on top of that. All it really does is transparently pickle the data written to the disk. ---------------------------------------------------------------------- Comment By: Brandon Hechinger (brandonh) Date: 2005-12-08 01:33 Message: Logged In: YES user_id=226421 We also get this error, though not using Python, but C. I'm not sure why people are so eager to dismiss it as an issue here, however, for it might be something your Python is doing with the Berkeley DB interface which could be improved. In our case, there is a similarity -- the site accesses the database(s) at relatively high frequency, and we use our own locking system to prevent any conflict (allowing multiple readers and exclusive writers -- writers not so much as generating a path to the database, let alone opening it, until they obtain the separate lock handled by our software). Periodically one of the databases will have an error when reading a key, and this error will remain until the database is repaired. The error return code is -30987. It's not 100% conclusive if it happens primarily on frequently accessed databases or not, and were it the case, it is not clear whether that's just because it occurs because of the high volume of access, or just because their volume increases the likelihood of encountering an error. In any case, our locking mechanisms (we've tried more than one) do lock prior to the database being opened at all, and are handled in a multi-reader single-writer way. Again, it's not clear if it's a Berkeley DB problem, or a problem with the *way* we are accessing/using Berkeley DB. Until this is known, I don't think it should be so quickly blown off that it's not a Python issue -- even if a bit of resources of the Python resources went into finding a Berkeley DB problem, would it result in such a bad world? :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-16 15:50 Message: Logged In: YES user_id=413 DB_RUNRECOVERY errors are a sleepycat BerkeleyDB internal error and don't have anything to do with the python library wrapper. For help in tracking them down I suggest using the latest BerkeleyDB version and ask with example code on the berkeleydb newsgroups or ask sleepycat themselves (they don't bite, they're friendly). closing this bug as its not a python or extension module bug. If you're looking for a multiprocess aware BerkeleyDB shelve support, that should be a feature request (ideally with an example implementation :). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-22 16:04 Message: Logged In: YES user_id=250749 I can sympathise with your POV, but shelve has a documented restriction that it is not supported for multiuser user use without specific external support - that is multiple readers are Ok, but writing requires exclusive access to the shelve database. As you are using it in such an environment, it is up to you to guarantee the required safety. The error being reported is highly likely to be a consequence of your locking scheme being inadequate for use with the BerkeleyDB environment, at least on that system, and my suggestion that you take this up in a BerkeleyDB forum was directed at you getting sufficient information to improve your locking scheme to avoid the problem you see. I think you are a little optimistic expecting the shelve module (let alone the anydbm module) to cope with exceptions arising from use outside its documented restrictions - and BerkeleyDB supports lots of capability beyond the scope of the functionality used by shelve and anydbm and the exceptions to go with that. If you care about the shelve storage format, you can force the type of storage by creating an empty database of the format of your choice, provided that that format is supported by anydbm. With a bit of care, you should be able to convert a shelve from one format to another, within the anydbm format support restriction. While it might be nice to have some format control, anydbm's purpose is hide the database format/interface. If you care about the format, you're expected to use the desired interface module directly. ---------------------------------------------------------------------- Comment By: Predrag Miocinovic (predragm) Date: 2003-12-21 20:48 Message: Logged In: YES user_id=860222 I find the last comment somewhat unsatisfactory. While this appears to be BerkeleyDB issue (and w/o going into details why the exception gets thrown), it's strange that Shelve module doesn't handle this more gracefully. Since the concept of Shelve is hiding implementation details from the application, having to catch BerkeleyDB exceptions for simple shelf operations is bit over the top. If I move to another system, using different underlying DB (as given by anydbm), will I have to catch new set of exceptions all over again? Shelve (or anydbm) should either provide ability to select underlying DB implementation to use, or it should handle all DB implementation aspects so that it is trully transparent to the end user. Just my $0.02. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-21 03:50 Message: Logged In: YES user_id=250749 As far as I can make out, what you're seeing is a BerkeleyDB issue, and bsddb is just reporting what BDB is telling it. DB_RUNRECOVERY (-30987 on DB 3.3, -30981 on DB 4.0) is documented as (quoted from DB4.0 HTML docs): "There exists a class of errors that Berkeley DB considers fatal to an entire Berkeley DB environment. An example of this type of error is a corrupted database or a log write failure because the disk is out of free space. The only way to recover from these failures is to have all threads of control exit the Berkeley DB environment, run recovery of the environment, and re-enter Berkeley DB." Therefore I think you should to followup this in a BerkeleyDB forum. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 From noreply at sourceforge.net Thu Dec 8 18:54:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 09:54:53 -0800 Subject: [ python-Feature Requests-816628 ] request for bugs.python.org Message-ID: Feature Requests item #816628, was opened at 2003-10-02 11:55 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: A.M. Kuchling (akuchling) Summary: request for bugs.python.org Initial Comment: Many projects (gentoo, gnome, kde...) have the conveninent url for accessing the bug database: bugs.python.org That would be cool. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 12:54 Message: Logged In: YES user_id=11375 bugs.python.org has been created; I've set up Apache to redirect it to the top page of the bug tracker. http://bugs.python.org/ redirects to the specific bug, same as http://python.org/sf/. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 08:46 Message: Logged In: YES user_id=11375 I don't know if Thomas looks at things in the Python bug tracker. I've written him directly, asking for bugs.python.org to be created, and will do the Apache tweaking once the name has been created. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-02 09:15 Message: Logged In: YES user_id=12800 I agree that this is a good idea, and easy to do. Let's add this hostname, point it at www.python.org, then set up an Apache rewrite rule to redirect to http://sourceforge.net/tracker/?group_id=5470&atid=105470 Assigning to Thomas for the dns tricks. I'll be happy to handle the Apache set up once the hostname has been added. ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2004-01-01 10:15 Message: Logged In: YES user_id=233844 The goal is not to duplicate the sf page, just to provide an easier way to find it. bugs.python.org is very convenient and easy to remember. It saves time for the people reporting bugs because one does not have to skim through the 100 links of www.python.org to find where to report bugs. Other projects have adpoted it with success. There is nothing to lose by providing this shortcut. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 01:39 Message: Logged In: YES user_id=80475 We now own the domain, but I don't see an advantage to duplicating what is on SF. The main website at www.python.org has a direct link on the main page. IMO, that is enough. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-10-02 12:15 Message: Logged In: YES user_id=12800 Even if it's a good idea, we can't do this until the PSF controls the python.org domain. I don't know what the status of that is, but I believe a transfer is in the works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 From noreply at sourceforge.net Thu Dec 8 22:45:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 13:45:22 -0800 Subject: [ python-Bugs-1376309 ] subprocess.CalledProcessError uses errno incorrectly Message-ID: Bugs item #1376309, was opened at 2005-12-08 15:14 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) >Assigned to: Peter ?strand (astrand) Summary: subprocess.CalledProcessError uses errno incorrectly Initial Comment: I have some code which uses subprocess.check_call(), which is buried in other code that catches an OSError, and does different things depending on OSError.errno. Since subprocess.CalledProcessError overloads errno for its own return code values, this leads to confusing error messages. The return code is NOT an errno, and I do not think this field should be overloaded in this way. Additionally, since OSError exceptions generally have an errno attribute set, and exception-handling code expects this, I do not think that CalledProcessError should subclass from it. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-12-08 15:27 Message: Logged In: YES user_id=987664 Ugh, this was supposed to be a bug, not a patch. Is there anyway to change this or should I just resumbit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 From noreply at sourceforge.net Thu Dec 8 22:50:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 13:50:28 -0800 Subject: [ python-Bugs-689895 ] Imports can deadlock Message-ID: Bugs item #689895, was opened at 2003-02-20 00:39 Message generated for change (Comment added) made by sitbon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=689895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: Imports can deadlock Initial Comment: [Just copying some discussion details from python-dev into this bug report so that we can reopen it to Python 2.4] [MAL] >> I wonder whether a general lock such as the one used in import >> is such a good idea. Perhaps it should only lock the importing >> of a specific module, keeping the locks in a dictionary indexed by >> module name instead of a static C variable ?! I've been thinking along the same lines. We could make the import locking much finer-grained, and limit the blocking only to threads that are importing a module that is in the middle of being loaded by some other thread. But this is hard work, and I suggest that we put this off until Python 2.4 so we can do it right. >> Then again it's hard to know the real name of the module being >> searched before finding it... There could be a short-lived lock for that problem. >> I see a more general problem here: the lock prevent starting >> up threaded applications which use client-server logic between >> the threads. If the application's main thread starts a client >> thread as a result of an import which then tries to import >> other Python modules, you have a deadlock. (At least that's how >> I understand the current implementation.) Correct. >> Don't know about others, but I frequently use the idiom of >> placing the server's main code in a separate module and then >> have small startup script importing this module. This kind >> of setup is also advertised for CGI programs, so it may not >> be uncommon out there. We had this problem with Zope2 -- I don't know why the import lock didn't bite us before, but we decided to change the Zope startup code so that you have to import Zope first and then, separately, make a call to start it. You could do the same for your application, and I recommend that Mark does the same for his. --Guido van Rossum (home page: http://www.python.org/~guido/) ---------------------------------------------------------------------- Comment By: Phillip Sitbon (sitbon) Date: 2005-12-08 13:50 Message: Logged In: YES user_id=1303233 Has anyone looked further into this? I seem to be having the same problem with a simple multithreaded program that imports from within thread functions. I didn't have the problem (at least not too often, but still in some cases) with 2.4.1 but now 2.4.2 has me deadlocking on the imports every time. It's a frustrating problem! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-20 00:40 Message: Logged In: YES user_id=38388 [eric at enthought.com] >[MAL] > >>> > I wonder whether a general lock such as the one used in import >>> > is such a good idea. Perhaps it should only lock the importing >>> > of a specific module, keeping the locks in a dictionary indexed by >>> > module name instead of a static C variable ?! I am interested in this also. >> >> [Guido] >> I've been thinking along the same lines. We could make the import >> locking much finer-grained, and limit the blocking only to threads >> that are importing a module that is in the middle of being loaded by >> some other thread. >> >> But this is hard work, and I suggest that we put this off until Python >> 2.4 so we can do it right. I ran into this exact thing when trying to get wxPython windows (data plots) to co-exist peacefully on the screen in parallel with an interactive shell. The module is called gui_thread, and we use it in SciPy. http://www.scipy.org/site_content/tutorials/gui_thread The command line took the main thread, and a wxPython app was started in the background thread. The first import of wxPython had to occur in the background thread for wxPython's to be happy. Initially, I put a lock in the import of gui_thread which waited for the wxPython import to complete before allowing the gui_thread import to complete. If 'import gui_thread' is the first statement executed, this guarantees that wxPython is always imported first in the background thread. Unfortunately, it also causes deadlock because of the import lock. A discussion that occurred about this problem on the thread-sig with is summarized here: http://www.scipy.org/site_content/tutorials/import_thread_lock_discussio n It includes an alternative version of several import.c routines (compared to 1.5.2 I believe) that solved my problem as proposed by MAL above and passed all the regression tests at the time. I just plugged the code into the 2.3CVS, and it mainly works. But, there are some import related errors in the regression tests for: test_threaded_import test_loggingllbacks I could spend some time on these if there is interest in getting this in the current release. Also, this code would need review by someone that is an expert on the subtleties of the import code to make sure it is sound. Let me know, and I'll submit a patch with of the current code. eric ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=689895&group_id=5470 From noreply at sourceforge.net Fri Dec 9 02:03:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 17:03:44 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 17: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=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ken668 (ken668) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Fri Dec 9 22:43:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Dec 2005 13:43:57 -0800 Subject: [ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char. Message-ID: Bugs item #1377394, was opened at 2005-12-09 15:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 From noreply at sourceforge.net Fri Dec 9 23:04:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Dec 2005 14:04:36 -0800 Subject: [ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char. Message-ID: Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 23:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the Python internal Unicode encoding (unicode_internal) ? This is an encoding that is only used Python internally and should not be used for anything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 From noreply at sourceforge.net Sat Dec 10 00:17:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Dec 2005 15:17:18 -0800 Subject: [ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char. Message-ID: Bugs item #1377394, was opened at 2005-12-09 15:43 Message generated for change (Comment added) made by superwesman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt ---------------------------------------------------------------------- >Comment By: superwesman (superwesman) Date: 2005-12-09 17:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() should complain. If it is valid, it should perform consistently, IMHO. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 16:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the Python internal Unicode encoding (unicode_internal) ? This is an encoding that is only used Python internally and should not be used for anything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 From noreply at sourceforge.net Sat Dec 10 11:57:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 02:57:26 -0800 Subject: [ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char. Message-ID: Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:57 Message: Logged In: YES user_id=1188172 I'd suggest unicode_internal to be removed from the docs. ---------------------------------------------------------------------- Comment By: superwesman (superwesman) Date: 2005-12-10 00:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() should complain. If it is valid, it should perform consistently, IMHO. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 23:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the Python internal Unicode encoding (unicode_internal) ? This is an encoding that is only used Python internally and should not be used for anything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 From noreply at sourceforge.net Sat Dec 10 12:07:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 03:07:07 -0800 Subject: [ python-Bugs-1370322 ] Float marshaling problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 20:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Michael Hudson (mwh) >Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 12:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 11:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Sat Dec 10 12:43:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 03:43:32 -0800 Subject: [ python-Bugs-1370322 ] Float marshaling problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 19:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Sat Dec 10 12:47:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 03:47:13 -0800 Subject: [ python-Bugs-1370322 ] Float marshaling problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 19:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Sat Dec 10 14:35:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 05:35:26 -0800 Subject: [ python-Bugs-1370322 ] Float marshaling problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 20:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 14:35 Message: Logged In: YES user_id=1188172 Yes, it is reproducable. If it's local to me, I don't know what could be causing it. I have a SVN tree without local changes on my local box and my laptop, and both of them show the same bug. I'll boot into some CD Linux later and see if the other environment makes it vanish. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 12:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 11:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Sat Dec 10 14:42:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 05:42:57 -0800 Subject: [ python-Bugs-1370322 ] Float marshaling problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 19:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-10 13:42 Message: Logged In: YES user_id=6656 Umpf. I suppose the one remaining thing is you say you use "make clean". This makes me very faintly suspicious that "make clean" doesn't really clean everything... could you maybe try a clean checkout? Clutching at straws here, obviously. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 13:35 Message: Logged In: YES user_id=1188172 Yes, it is reproducable. If it's local to me, I don't know what could be causing it. I have a SVN tree without local changes on my local box and my laptop, and both of them show the same bug. I'll boot into some CD Linux later and see if the other environment makes it vanish. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 11:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Sat Dec 10 18:05:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 09:05:41 -0800 Subject: [ python-Bugs-1370322 ] Float marshaling problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 20:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 18:05 Message: Logged In: YES user_id=1188172 Yep, after "make distclean" and even a fresh checkout the problem is there. I configured with and without "--with-pydebug". Okay, Michael, you are rehabilitated: I restored floatobject.c to the state before your patch, and it behaves the same. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 14:42 Message: Logged In: YES user_id=6656 Umpf. I suppose the one remaining thing is you say you use "make clean". This makes me very faintly suspicious that "make clean" doesn't really clean everything... could you maybe try a clean checkout? Clutching at straws here, obviously. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 14:35 Message: Logged In: YES user_id=1188172 Yes, it is reproducable. If it's local to me, I don't know what could be causing it. I have a SVN tree without local changes on my local box and my laptop, and both of them show the same bug. I'll boot into some CD Linux later and see if the other environment makes it vanish. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 12:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 11:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Sat Dec 10 18:48:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 09:48:22 -0800 Subject: [ python-Bugs-1010952 ] running test_codecmaps_* takes too much effort Message-ID: Bugs item #1010952, was opened at 2004-08-18 04:13 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Hye-Shik Chang (perky) Summary: running test_codecmaps_* takes too much effort Initial Comment: The only way I've found to actually run the codecmap tests is by running it over and over again, downloading the missing files when a test complains in between, until the tests no longer complains. E.g $ make test - test_codecmap_jp complains about a missing file - download this file $ make test - test_codecmap_jp complains about another missing filie - ... Another problem: it is completely unclear where I should place the downloaded files. I've worked around this by placing the files in Lib/test and patching test_multibytecodec_support to look for the files in os.path.dirname(__file__): cvs diff: Diffing . Index: test_multibytecodec_support.py ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Lib/test/ test_multibytecodec_support.py,v retrieving revision 1.5 diff -r1.5 test_multibytecodec_support.py 165a166 > self.mapfilename = os.path.join(os.path.dirname(__file__), self.mapfilename) It would be nice if there were a document that described what should be done to run these tests, adding the required files to CVS would be fine too :-) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-11 02:48 Message: Logged In: YES user_id=55188 Fixed in r41637. Thank you! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-08-30 16:06 Message: Logged In: YES user_id=55188 I wrote a patch that draws on lemburg's suggestion. Please test it: SF #1276356. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-10-14 05:04 Message: Logged In: YES user_id=38388 Just a suggestion: Why don't we add a new resource option to the test scripts and then have the tests download the files from the Internet as necessary ?! ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-14 04:59 Message: Logged In: YES user_id=469548 How about adding the files to nondist? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-14 00:12 Message: Logged In: YES user_id=29957 Could we at least get a single tarball/zip file of all of the files? At the moment, it takes a serious amount of effort to fetch all the files. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 16:26 Message: Logged In: YES user_id=21627 Adding the files to the CVS is unacceptable, because they would then end up in the distribution, and their size is considered unacceptable for distribution (let alone copyright issues with these files). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-18 04:19 Message: Logged In: YES user_id=580910 test_normalization suffers from a simular problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 From noreply at sourceforge.net Sat Dec 10 22:20:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 13:20:45 -0800 Subject: [ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs Message-ID: Bugs item #1377858, was opened at 2005-12-10 22: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=1377858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Nobody/Anonymous (nobody) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 From noreply at sourceforge.net Sun Dec 11 00:26:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 15:26:59 -0800 Subject: [ python-Bugs-1377897 ] Bus error in ast Message-ID: Bugs item #1377897, was opened at 2005-12-10 17:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377897&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Bus error in ast Initial Comment: Today I got a bus error trying to install the latest version of setuptools from the sandox after a fresh svn up of both and install of Python from the trunk on my Mac ()SX 10.3.9). Running under gdb it croaked at line 3033 of ast.c. Here's the backtrace: #0 ast_for_stmt (c=0xbfffda40, n=0x53d1b0) at ../Python/ast.c:3033 #1 0x00088060 in ast_for_suite (c=0xbfffda40, n=0x574e30) at ../ Python/ast.c:2561 #2 0x000890cc in ast_for_funcdef (c=0xbfffda40, n=0x3bcf50) at ../ Python/ast.c:896 #3 0x00088014 in ast_for_suite (c=0xbfffda40, n=0x574d18) at ../ Python/ast.c:2551 #4 0x0008b14c in ast_for_classdef (c=0xbfffda40, n=0x3bc9c8) at ../ Python/ast.c:2975 #5 0x00086a5c in PyAST_FromNode (n=0x3c28c0, flags=0x0, filename=0x1048d9c "build/bdist.darwin-7.9.0-Power_Macintosh/ egg/setuptools/tests/test_resources.py") at ../Python/ast.c:297 #6 0x0000d98c in Py_CompileStringFlags (str=0xbfffda40 "", filename=0x1048d9c "build/bdist.darwin-7.9.0-Power_Macintosh/ egg/setuptools/tests/test_resources.py", start=557152, flags=0xbfffdb5c) at ../Python/pythonrun.c:1275 #7 0x000a4eac in builtin_compile (self=0xbfffda40, args=0x0) at ../ Python/bltinmodule.c:457 #8 0x0007e154 in call_function (pp_stack=0xbfffdc3c, oparg=0) at ../ Python/ceval.c:3565 #9 0x0007bcb4 in PyEval_EvalFrameEx (f=0x842a10, throw=131) at ../Python/ceval.c:2181 #10 0x0007cd68 in PyEval_EvalCodeEx (co=0x842b98, globals=0x0, locals=0xb622c, args=0x842b5c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=3, closure=0x0) at ../Python/ ceval.c:2739 #11 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x3, n=8661852, na=5245749, nk=213) at ../Python/ceval.c:3658 #12 0x0007e22c in call_function (pp_stack=0xbfffde8c, oparg=0) at ../Python/ceval.c:3586 #13 0x0007bcb4 in PyEval_EvalFrameEx (f=0x850410, throw=131) at ../Python/ceval.c:2181 #14 0x0007cd68 in PyEval_EvalCodeEx (co=0x8505bc, globals=0x0, locals=0xb622c, args=0x85055c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=7, closure=0x0) at ../Python/ ceval.c:2739 #15 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x3, n=8717660, na=5245749, nk=213) at ../Python/ceval.c:3658 #16 0x0007e22c in call_function (pp_stack=0xbfffe0dc, oparg=0) at ../Python/ceval.c:3586 #17 0x0007bcb4 in PyEval_EvalFrameEx (f=0x837010, throw=131) at ../Python/ceval.c:2181 #18 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x401, n=8614236, na=5245749, nk=213) at ../Python/ceval.c:3647 #19 0x0007e22c in call_function (pp_stack=0xbfffe28c, oparg=0) at ../Python/ceval.c:3586 #20 0x0007bcb4 in PyEval_EvalFrameEx (f=0x859610, throw=131) at ../Python/ceval.c:2181 #21 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8755036, na=5245749, nk=213) at ../Python/ceval.c:3647 #22 0x0007e22c in call_function (pp_stack=0xbfffe43c, oparg=0) at ../Python/ceval.c:3586 #23 0x0007bcb4 in PyEval_EvalFrameEx (f=0x861e10, throw=131) at ../Python/ceval.c:2181 #24 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x0, n=8789852, na=5245749, nk=213) at ../Python/ceval.c:3647 #25 0x0007e22c in call_function (pp_stack=0xbfffe5ec, oparg=0) at ../Python/ceval.c:3586 #26 0x0007bcb4 in PyEval_EvalFrameEx (f=0x849810, throw=131) at ../Python/ceval.c:2181 #27 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8690012, na=5245749, nk=213) at ../Python/ceval.c:3647 #28 0x0007e22c in call_function (pp_stack=0xbfffe79c, oparg=0) at ../Python/ceval.c:3586 #29 0x0007bcb4 in PyEval_EvalFrameEx (f=0x860610, throw=131) at ../Python/ceval.c:2181 #30 0x0007cd68 in PyEval_EvalCodeEx (co=0x860778, globals=0x0, locals=0xb622c, args=0x86075c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=0, closure=0x0) at ../Python/ ceval.c:2739 #31 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8783708, na=5245749, nk=213) at ../Python/ceval.c:3658 #32 0x0007e22c in call_function (pp_stack=0xbfffe9ec, oparg=0) at ../Python/ceval.c:3586 #33 0x0007bcb4 in PyEval_EvalFrameEx (f=0x40dc40, throw=131) at ../Python/ceval.c:2181 #34 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x101, n=4251020, na=5245749, nk=213) at ../Python/ceval.c:3647 #35 0x0007e22c in call_function (pp_stack=0xbfffeb9c, oparg=0) at ../Python/ceval.c:3586 #36 0x0007bcb4 in PyEval_EvalFrameEx (f=0x42a500, throw=131) at ../Python/ceval.c:2181 #37 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x0, n=4367948, na=5245749, nk=213) at ../Python/ceval.c:3647 #38 0x0007e22c in call_function (pp_stack=0xbfffed4c, oparg=0) at ../Python/ceval.c:3586 #39 0x0007bcb4 in PyEval_EvalFrameEx (f=0x430540, throw=131) at ../Python/ceval.c:2181 #40 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=4392588, na=5245749, nk=213) at ../Python/ceval.c:3647 #41 0x0007e22c in call_function (pp_stack=0xbfffeefc, oparg=0) at ../ Python/ceval.c:3586 #42 0x0007bcb4 in PyEval_EvalFrameEx (f=0x430380, throw=131) at ../Python/ceval.c:2181 #43 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=4392140, na=5245749, nk=213) at ../Python/ceval.c:3647 #44 0x0007e22c in call_function (pp_stack=0xbffff0ac, oparg=0) at ../ Python/ceval.c:3586 #45 0x0007bcb4 in PyEval_EvalFrameEx (f=0x86a410, throw=131) at ../Python/ceval.c:2181 #46 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x0, n=8824156, na=5245749, nk=213) at ../Python/ceval.c:3647 #47 0x0007e22c in call_function (pp_stack=0xbffff25c, oparg=0) at ../ Python/ceval.c:3586 #48 0x0007bcb4 in PyEval_EvalFrameEx (f=0x80b810, throw=131) at ../Python/ceval.c:2181 #49 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8436060, na=5245749, nk=213) at ../Python/ceval.c:3647 #50 0x0007e22c in call_function (pp_stack=0xbffff40c, oparg=0) at ../ Python/ceval.c:3586 #51 0x0007bcb4 in PyEval_EvalFrameEx (f=0x4085c0, throw=131) at ../Python/ceval.c:2181 #52 0x0007cd68 in PyEval_EvalCodeEx (co=0x40872c, globals=0x0, locals=0xb622c, args=0x40870c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=0, closure=0x0) at ../Python/ ceval.c:2739 #53 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x0, n=4228876, na=5245749, nk=213) at ../Python/ceval.c:3658 #54 0x0007e22c in call_function (pp_stack=0xbffff65c, oparg=0) at ../ Python/ceval.c:3586 #55 0x0007bcb4 in PyEval_EvalFrameEx (f=0x835610, throw=131) at ../Python/ceval.c:2181 #56 0x0007cd68 in PyEval_EvalCodeEx (co=0x8357e8, globals=0x0, locals=0xb622c, args=0x42444282, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=0, closure=0x0) at ../Python/ ceval.c:2739 #57 0x000801ec in PyEval_EvalCode (co=0xbfffda40, globals=0x0, locals=0x4) at ../Python/ceval.c:490 #58 0x0000cb90 in run_mod (mod=0xbfffda40, filename=0x0, globals=0x1100, locals=0x42444282, flags=0x5) at ../Python/ pythonrun.c:1198 #59 0x0000cb28 in PyRun_FileExFlags (fp=0x8357e8, filename=0xbffffba9 "setup.py", start=4, globals=0x835610, locals=0x3b6940, closeit=1, flags=0x40a19d) at ../Python/ pythonrun.c:1175 #60 0x0000c318 in PyRun_SimpleFileExFlags (fp=0xa000a8d0, filename=0xbffffba9 "setup.py", closeit=1, flags=0xbffff9b4) at ../ Python/pythonrun.c:823 #61 0x00006510 in Py_Main (argc=3660512, argv=0xbffffbad) at ../ Modules/main.c:492 #62 0x00001c48 in _start (argc=3660512, argv=0xa000a8d0, envp=0xbffffbad) at /SourceCache/Csu/Csu-47/crt.c:267 #63 0x8fe1a278 in __dyld__dyld_start () ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377897&group_id=5470 From noreply at sourceforge.net Sun Dec 11 00:44:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 15:44:41 -0800 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 03:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-12-10 15:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 02:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 12:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-22 21:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 00:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 04:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Sun Dec 11 01:41:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 16:41:39 -0800 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 11:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-11 00:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 23:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 10:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 20:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-23 05:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 08:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 13:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 13:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 13:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 13:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 11:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 11:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Sun Dec 11 07:48:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 22:48:03 -0800 Subject: [ python-Bugs-1378022 ] source utf8 Message-ID: Bugs item #1378022, was opened at 2005-12-11 06: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=1378022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: zhao (ibear) Assigned to: Nobody/Anonymous (nobody) Summary: source utf8 Initial Comment: winxp sp2(chinese or japanese) and python 2.42 i have created a utf8 source file with BOM_UTF8 if i add a '#coding: utf8' at first line and run it, the python interpreter will crash ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 From noreply at sourceforge.net Sun Dec 11 21:05:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 12:05:38 -0800 Subject: [ python-Bugs-1370322 ] Float marshaling problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 11:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:05 Message: Logged In: YES user_id=33168 I can't reproduce (make test) on linux 2.6, gcc 3.4.4, only diff is amd64. I have some outstanding changes, but none that should affect the outcome. Sorry, I don't know what to tell you, can you try to debug any more? Maybe run under valgrind (or other memory debugger) and see if there's a memory issue. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 09:05 Message: Logged In: YES user_id=1188172 Yep, after "make distclean" and even a fresh checkout the problem is there. I configured with and without "--with-pydebug". Okay, Michael, you are rehabilitated: I restored floatobject.c to the state before your patch, and it behaves the same. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 05:42 Message: Logged In: YES user_id=6656 Umpf. I suppose the one remaining thing is you say you use "make clean". This makes me very faintly suspicious that "make clean" doesn't really clean everything... could you maybe try a clean checkout? Clutching at straws here, obviously. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 05:35 Message: Logged In: YES user_id=1188172 Yes, it is reproducable. If it's local to me, I don't know what could be causing it. I have a SVN tree without local changes on my local box and my laptop, and both of them show the same bug. I'll boot into some CD Linux later and see if the other environment makes it vanish. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 03:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 03:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 03:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 02:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Sun Dec 11 21:09:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 12:09:14 -0800 Subject: [ python-Bugs-1370197 ] memory leak - ast_error_finish Message-ID: Bugs item #1370197, was opened at 2005-11-30 08:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: AST >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Neal Norwitz (nnorwitz) Summary: memory leak - ast_error_finish Initial Comment: http://svn.python.org/view/python/trunk/Python/ast.c? rev=41486&view=markup function ast_error_finish It first gets the errstr, for a possible early out. If there is an error string, it is increfed, but it is not decrefed on the other early outs. (lineno==-1 and failure to build a tmp. """ Py_INCREF(errstr); lineno = PyInt_AsLong(PyTuple_GetItem(value, 1)); if (lineno == -1) return; Py_DECREF(value); loc = PyErr_ProgramText(filename, lineno); if (!loc) { Py_INCREF(Py_None); loc = Py_None; } tmp = Py_BuildValue("(ziOO)", filename, lineno, Py_None, loc); Py_DECREF(loc); if (!tmp) return; value = Py_BuildValue("(OO)", errstr, tmp); Py_DECREF(errstr); """ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:09 Message: Logged In: YES user_id=33168 You are correct. I thought I had tested, but test_grammar failed with my removal. I added the DECREFs. Committed revision 41641. Thanks for tracking this down. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-12-02 11:14 Message: Logged In: YES user_id=764593 No, though it took me a *long* time to see why, because the &value pointer is reused. As best I understand it, PyErr_Fetch may leave (the initial value of) value with the only reference to errstr. There is a Py_DECREF(value) after successfully retrieving a line number, but before using errstr to build the (new value of) value for PyErr_Restore. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-01 21:22 Message: Logged In: YES user_id=33168 ISTM that we don't need the INCREF or DECREF for errstr. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470 From noreply at sourceforge.net Sun Dec 11 21:12:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 12:12:52 -0800 Subject: [ python-Bugs-1377897 ] Bus error in ast Message-ID: Bugs item #1377897, was opened at 2005-12-10 15:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377897&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Neal Norwitz (nnorwitz) Summary: Bus error in ast Initial Comment: Today I got a bus error trying to install the latest version of setuptools from the sandox after a fresh svn up of both and install of Python from the trunk on my Mac ()SX 10.3.9). Running under gdb it croaked at line 3033 of ast.c. Here's the backtrace: #0 ast_for_stmt (c=0xbfffda40, n=0x53d1b0) at ../Python/ast.c:3033 #1 0x00088060 in ast_for_suite (c=0xbfffda40, n=0x574e30) at ../ Python/ast.c:2561 #2 0x000890cc in ast_for_funcdef (c=0xbfffda40, n=0x3bcf50) at ../ Python/ast.c:896 #3 0x00088014 in ast_for_suite (c=0xbfffda40, n=0x574d18) at ../ Python/ast.c:2551 #4 0x0008b14c in ast_for_classdef (c=0xbfffda40, n=0x3bc9c8) at ../ Python/ast.c:2975 #5 0x00086a5c in PyAST_FromNode (n=0x3c28c0, flags=0x0, filename=0x1048d9c "build/bdist.darwin-7.9.0-Power_Macintosh/ egg/setuptools/tests/test_resources.py") at ../Python/ast.c:297 #6 0x0000d98c in Py_CompileStringFlags (str=0xbfffda40 "", filename=0x1048d9c "build/bdist.darwin-7.9.0-Power_Macintosh/ egg/setuptools/tests/test_resources.py", start=557152, flags=0xbfffdb5c) at ../Python/pythonrun.c:1275 #7 0x000a4eac in builtin_compile (self=0xbfffda40, args=0x0) at ../ Python/bltinmodule.c:457 #8 0x0007e154 in call_function (pp_stack=0xbfffdc3c, oparg=0) at ../ Python/ceval.c:3565 #9 0x0007bcb4 in PyEval_EvalFrameEx (f=0x842a10, throw=131) at ../Python/ceval.c:2181 #10 0x0007cd68 in PyEval_EvalCodeEx (co=0x842b98, globals=0x0, locals=0xb622c, args=0x842b5c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=3, closure=0x0) at ../Python/ ceval.c:2739 #11 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x3, n=8661852, na=5245749, nk=213) at ../Python/ceval.c:3658 #12 0x0007e22c in call_function (pp_stack=0xbfffde8c, oparg=0) at ../Python/ceval.c:3586 #13 0x0007bcb4 in PyEval_EvalFrameEx (f=0x850410, throw=131) at ../Python/ceval.c:2181 #14 0x0007cd68 in PyEval_EvalCodeEx (co=0x8505bc, globals=0x0, locals=0xb622c, args=0x85055c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=7, closure=0x0) at ../Python/ ceval.c:2739 #15 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x3, n=8717660, na=5245749, nk=213) at ../Python/ceval.c:3658 #16 0x0007e22c in call_function (pp_stack=0xbfffe0dc, oparg=0) at ../Python/ceval.c:3586 #17 0x0007bcb4 in PyEval_EvalFrameEx (f=0x837010, throw=131) at ../Python/ceval.c:2181 #18 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x401, n=8614236, na=5245749, nk=213) at ../Python/ceval.c:3647 #19 0x0007e22c in call_function (pp_stack=0xbfffe28c, oparg=0) at ../Python/ceval.c:3586 #20 0x0007bcb4 in PyEval_EvalFrameEx (f=0x859610, throw=131) at ../Python/ceval.c:2181 #21 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8755036, na=5245749, nk=213) at ../Python/ceval.c:3647 #22 0x0007e22c in call_function (pp_stack=0xbfffe43c, oparg=0) at ../Python/ceval.c:3586 #23 0x0007bcb4 in PyEval_EvalFrameEx (f=0x861e10, throw=131) at ../Python/ceval.c:2181 #24 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x0, n=8789852, na=5245749, nk=213) at ../Python/ceval.c:3647 #25 0x0007e22c in call_function (pp_stack=0xbfffe5ec, oparg=0) at ../Python/ceval.c:3586 #26 0x0007bcb4 in PyEval_EvalFrameEx (f=0x849810, throw=131) at ../Python/ceval.c:2181 #27 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8690012, na=5245749, nk=213) at ../Python/ceval.c:3647 #28 0x0007e22c in call_function (pp_stack=0xbfffe79c, oparg=0) at ../Python/ceval.c:3586 #29 0x0007bcb4 in PyEval_EvalFrameEx (f=0x860610, throw=131) at ../Python/ceval.c:2181 #30 0x0007cd68 in PyEval_EvalCodeEx (co=0x860778, globals=0x0, locals=0xb622c, args=0x86075c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=0, closure=0x0) at ../Python/ ceval.c:2739 #31 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8783708, na=5245749, nk=213) at ../Python/ceval.c:3658 #32 0x0007e22c in call_function (pp_stack=0xbfffe9ec, oparg=0) at ../Python/ceval.c:3586 #33 0x0007bcb4 in PyEval_EvalFrameEx (f=0x40dc40, throw=131) at ../Python/ceval.c:2181 #34 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x101, n=4251020, na=5245749, nk=213) at ../Python/ceval.c:3647 #35 0x0007e22c in call_function (pp_stack=0xbfffeb9c, oparg=0) at ../Python/ceval.c:3586 #36 0x0007bcb4 in PyEval_EvalFrameEx (f=0x42a500, throw=131) at ../Python/ceval.c:2181 #37 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x0, n=4367948, na=5245749, nk=213) at ../Python/ceval.c:3647 #38 0x0007e22c in call_function (pp_stack=0xbfffed4c, oparg=0) at ../Python/ceval.c:3586 #39 0x0007bcb4 in PyEval_EvalFrameEx (f=0x430540, throw=131) at ../Python/ceval.c:2181 #40 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=4392588, na=5245749, nk=213) at ../Python/ceval.c:3647 #41 0x0007e22c in call_function (pp_stack=0xbfffeefc, oparg=0) at ../ Python/ceval.c:3586 #42 0x0007bcb4 in PyEval_EvalFrameEx (f=0x430380, throw=131) at ../Python/ceval.c:2181 #43 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=4392140, na=5245749, nk=213) at ../Python/ceval.c:3647 #44 0x0007e22c in call_function (pp_stack=0xbffff0ac, oparg=0) at ../ Python/ceval.c:3586 #45 0x0007bcb4 in PyEval_EvalFrameEx (f=0x86a410, throw=131) at ../Python/ceval.c:2181 #46 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x0, n=8824156, na=5245749, nk=213) at ../Python/ceval.c:3647 #47 0x0007e22c in call_function (pp_stack=0xbffff25c, oparg=0) at ../ Python/ceval.c:3586 #48 0x0007bcb4 in PyEval_EvalFrameEx (f=0x80b810, throw=131) at ../Python/ceval.c:2181 #49 0x0007e3a8 in fast_function (func=0xbfffda40, pp_stack=0x1, n=8436060, na=5245749, nk=213) at ../Python/ceval.c:3647 #50 0x0007e22c in call_function (pp_stack=0xbffff40c, oparg=0) at ../ Python/ceval.c:3586 #51 0x0007bcb4 in PyEval_EvalFrameEx (f=0x4085c0, throw=131) at ../Python/ceval.c:2181 #52 0x0007cd68 in PyEval_EvalCodeEx (co=0x40872c, globals=0x0, locals=0xb622c, args=0x40870c, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=0, closure=0x0) at ../Python/ ceval.c:2739 #53 0x0007e438 in fast_function (func=0xbfffda40, pp_stack=0x0, n=4228876, na=5245749, nk=213) at ../Python/ceval.c:3658 #54 0x0007e22c in call_function (pp_stack=0xbffff65c, oparg=0) at ../ Python/ceval.c:3586 #55 0x0007bcb4 in PyEval_EvalFrameEx (f=0x835610, throw=131) at ../Python/ceval.c:2181 #56 0x0007cd68 in PyEval_EvalCodeEx (co=0x8357e8, globals=0x0, locals=0xb622c, args=0x42444282, argcount=4194752, kws=0x0, kwcount=498148, defs=0x0, defcount=0, closure=0x0) at ../Python/ ceval.c:2739 #57 0x000801ec in PyEval_EvalCode (co=0xbfffda40, globals=0x0, locals=0x4) at ../Python/ceval.c:490 #58 0x0000cb90 in run_mod (mod=0xbfffda40, filename=0x0, globals=0x1100, locals=0x42444282, flags=0x5) at ../Python/ pythonrun.c:1198 #59 0x0000cb28 in PyRun_FileExFlags (fp=0x8357e8, filename=0xbffffba9 "setup.py", start=4, globals=0x835610, locals=0x3b6940, closeit=1, flags=0x40a19d) at ../Python/ pythonrun.c:1175 #60 0x0000c318 in PyRun_SimpleFileExFlags (fp=0xa000a8d0, filename=0xbffffba9 "setup.py", closeit=1, flags=0xbffff9b4) at ../ Python/pythonrun.c:823 #61 0x00006510 in Py_Main (argc=3660512, argv=0xbffffbad) at ../ Modules/main.c:492 #62 0x00001c48 in _start (argc=3660512, argv=0xa000a8d0, envp=0xbffffbad) at /SourceCache/Csu/Csu-47/crt.c:267 #63 0x8fe1a278 in __dyld__dyld_start () ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:12 Message: Logged In: YES user_id=33168 The problem was caused by multiple ; on a line. The line must also end with a semi-colon. Thanks, Skip. Committed revision 41642. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377897&group_id=5470 From noreply at sourceforge.net Sun Dec 11 21:13:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 12:13:54 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 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=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ken668 (ken668) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Sun Dec 11 21:15:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 12:15:07 -0800 Subject: [ python-Bugs-1376400 ] test_struct crashed, py2.3.5, solaris 10 Message-ID: Bugs item #1376400, was opened at 2005-12-08 08:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: rrogans (rrogans) Assigned to: Nobody/Anonymous (nobody) Summary: test_struct crashed, py2.3.5, solaris 10 Initial Comment: Hi, I am building python 2.3.5 on solaris 10 using gcc 3.3.2. Run I perform the test I get one test failure - test_struct crashes. Rgds, Richard >>>>>>>>>>>> trying std qQ on 1471797217424382203 == 0x146CDFC575FD18FBL trying std qQ on 1471797217424382204 == 0x146CDFC575FD18FCL trying std qQ on 1471797217424382205 == 0x146CDFC575FD18FDL test test_struct crashed -- exceptions.OverflowError: math range error Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals (), []) File "/home/richardr/app/Python- 2.3.5/Lib/test/test_struct.py", line 439, in ? test_705836() File "/home/richardr/app/Python- 2.3.5/Lib/test/test_struct.py", line 424, in test_705836 big = math.ldexp(big, 127 - 23) OverflowError: math range error 1 test failed: test_struct <<<<<<<<<<< ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:15 Message: Logged In: YES user_id=33168 Could you try disabling optimization and rebuilding python? Also, depending on which compiler you are using, ensure that you are using strict math. Sometimes the option is -ieee I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470 From noreply at sourceforge.net Sun Dec 11 22:09:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 13:09:11 -0800 Subject: [ python-Bugs-1378305 ] Import value 1e400 from pyc fails Message-ID: Bugs item #1378305, was opened at 2005-12-11 21: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=1378305&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Guenter Jantzen (gjantzen) Assigned to: Nobody/Anonymous (nobody) Summary: Import value 1e400 from pyc fails Initial Comment: ------------------------------------------- #file: bug.py #sys.version_info (2, 4, 2, 'final', 0) #Platform is Windows XP import sys, bug infinity = 1e400 if __name__ == "__main__": import bug print "Infinity is", bug.infinity ------------------------------------------ This code behaves correct using bug.py - when bug.pyc is not up to date / not exists: Infinity is 1.#INF and behaves wrong using bug.pyc - when bug.pyc is up to date: Infinity is 1.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 From noreply at sourceforge.net Sun Dec 11 22:18:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 13:18:35 -0800 Subject: [ python-Bugs-1373150 ] diffs in working copy after a build Message-ID: Bugs item #1373150, was opened at 2005-12-04 16:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Neal Norwitz (nnorwitz) Summary: diffs in working copy after a build Initial Comment: I habitually build python in a subdirectory of the checkout directory (cd build; ../configure; make). After I do this, "svn diff" says this: Index: Include/Python-ast.h ============================================= ====================== --- Include/Python-ast.h (revision 41584) +++ Include/Python-ast.h (working copy) @@ -1,4 +1,4 @@ -/* File automatically generated by ./Parser/asdl_c.py */ +/* File automatically generated by ../Parser/asdl_c.py */ #include "asdl.h" Index: Python/Python-ast.c ============================================= ====================== --- Python/Python-ast.c (revision 41584) +++ Python/Python-ast.c (working copy) @@ -1,4 +1,4 @@ -/* File automatically generated by ./Parser/asdl_c.py */ +/* File automatically generated by ../Parser/asdl_c.py */ #include "Python.h" #include "Python-ast.h" which is kind of annoying. "File automatically generated by asdl_c.py" would probably do fine for me. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 13:18 Message: Logged In: YES user_id=33168 I always wondered how Jeremy and I conflicted. This bugged me too, so it's fixed now. Parser/asdl_c.py is what it says (ie .../ is stripped). Committed revision 41644. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-04 17:17 Message: Logged In: YES user_id=6656 Yes, whatever gets rid of the Ms in my wc :) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-04 16:26 Message: Logged In: YES user_id=357491 Would changing the path to say /Parser/asdl_c.py work for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373150&group_id=5470 From noreply at sourceforge.net Mon Dec 12 03:10:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Dec 2005 18:10:23 -0800 Subject: [ python-Bugs-1378455 ] a problem of urllib using open_local_file Message-ID: Bugs item #1378455, was opened at 2005-12-12 11: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=1378455&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Weongyo Jeong (weongyo) Assigned to: Nobody/Anonymous (nobody) Summary: a problem of urllib using open_local_file Initial Comment: Hello. I'm sorry for my short english. I'm using python 2.4 on my windows system. But I have a problem. see below: -------------------->3----------------->3------- Traceback (most recent call last): File "main.py", line 57, in uploadproc UNNAMED_toplev.main (self.liststore.get_value (iter, i)) File "C:\Work\unnamed\UNNAMED_toplev.py", line 59, in main toplev_main (doc, TARGET_FILE) File "C:\Work\unnamed\UNNAMED_toplev.py", line 51, in toplev_main doc.documentElement.appendChild (UNNAMED_filehash.GetSHA1Info (doc, filepath )) File "C:\Work\unnamed\UNNAMED_filehash.py", line 19, in GetSHA1Info file = urllib.urlopen (filepath) File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 185, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 421, in open_file return self.open_local_file(url) File "C:\Python24\lib\urllib.py", line 435, in open_local_file raise IOError(e.errno, e.strerror, e.filename) IOError: [Errno 2] No such file or directory: '\C:\pse_signature.psr' -------------------->3----------------->3------- i made a simple GUI program with pygtk and do drag and drop a file from windows file explorer. It printed "file:///C:/pse_signature.psr" which is a type of "text/uri-list". But urllib can't process it. Is it a problem of urllib? I read a article which reported a same problem with my case in python 2.2. that "file:///C:/pse_signature.psr" string made by windows. not me. why this problem don't be fixed? are there any reasons? thanks for reading. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&group_id=5470 From noreply at sourceforge.net Mon Dec 12 12:50:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 03:50:03 -0800 Subject: [ python-Bugs-1378679 ] urllib2.HTTPBasicAuthHandler fails on non-default port Message-ID: Bugs item #1378679, was opened at 2005-12-12 17: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=1378679&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Gusarov (gusarov) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.HTTPBasicAuthHandler fails on non-default port Initial Comment: HTTPBasicAuthHandler (or, more precise, AbstractBasicAuthHandler) does not work when non- default port is in use: passwords added to it just not being passed back in answer to the 401 error code. Default port works fine. I tracked the problem with it to the HTTPPasswordMgr. find_user_password: it accepts 'authuri' and reduce it using reduce_uri(). AbstractBasicAuthHandler passes as 'authuri' parameter just hostname, in form 'myhost:myport' and this cause reduce_uri() to parse it as URI with schema 'myhost' and netloc 'myport', which is obviously wrong. Passing to the reduce_uri() hostname in form 'myhost' works fine. I placed the the program demonstrating the bug to the attach: it throws HTTPError in my case. Of course change the host, port, user and password to the reflecting your setup. given should be protected by the basic authentication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&group_id=5470 From noreply at sourceforge.net Mon Dec 12 12:53:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 03:53:31 -0800 Subject: [ python-Bugs-1290333 ] cjkcodec compile error under AIX 5.2 on symbol 100_encode Message-ID: Bugs item #1290333, was opened at 2005-09-14 02:55 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Deron Meranda (dmeranda) Assigned to: Hye-Shik Chang (perky) Summary: cjkcodec compile error under AIX 5.2 on symbol 100_encode Initial Comment: Trying to compile Python 2.4.1 under AIX 5.2 with the native cc compiler. When compiling the module cjkcodecs the compiler will fail with these errors on the source file Modules/cjkcodecs/_codecs_cn.c building '_codecs_cn' extension cc -DNDEBUG -O -I. -I/home/psgtools/aix52/build/Python-2.4.1/./Include -I/opt/cmax/psgtools/include -I/home/psgtools/aix52/build/Python-2.4.1/Include -I/home/psgtools/aix52/build/Python-2.4.1 -c /home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c -o build/temp.aix-5.2-2.4/_codecs_cn.o "/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c", line 431.3: 1506-206 (S) Suffix of integer constant 100_encode is not valid. "/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c", line 431.3: 1506-196 (W) Initialization between types "int(*)(union {...}*,const void*,const unsigned long**,unsigned long,unsigned char**,unsigned long,int)" and "int" is not allowed. and so on. This is happening because of the "hz" codec. Due to the way the source file uses the C preprocessor macro, and the fact that the preprocessor symbol "hz" is predefined as 100 on this platform, it is producing invalid lecical symbols such as "100_encode". The simple solution is to insert the following line in the source file immediately before the first reference to the name "hz": #undef hz ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-12 20:53 Message: Logged In: YES user_id=55188 Fixed in r41647. Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470 From noreply at sourceforge.net Mon Dec 12 13:10:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 04:10:41 -0800 Subject: [ python-Bugs-1378679 ] urllib2.HTTPBasicAuthHandler fails on non-default port Message-ID: Bugs item #1378679, was opened at 2005-12-12 17:50 Message generated for change (Comment added) made by gusarov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Gusarov (gusarov) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.HTTPBasicAuthHandler fails on non-default port Initial Comment: HTTPBasicAuthHandler (or, more precise, AbstractBasicAuthHandler) does not work when non- default port is in use: passwords added to it just not being passed back in answer to the 401 error code. Default port works fine. I tracked the problem with it to the HTTPPasswordMgr. find_user_password: it accepts 'authuri' and reduce it using reduce_uri(). AbstractBasicAuthHandler passes as 'authuri' parameter just hostname, in form 'myhost:myport' and this cause reduce_uri() to parse it as URI with schema 'myhost' and netloc 'myport', which is obviously wrong. Passing to the reduce_uri() hostname in form 'myhost' works fine. I placed the the program demonstrating the bug to the attach: it throws HTTPError in my case. Of course change the host, port, user and password to the reflecting your setup. given should be protected by the basic authentication. ---------------------------------------------------------------------- >Comment By: Mikhail Gusarov (gusarov) Date: 2005-12-12 18:10 Message: Logged In: YES user_id=501458 Problem was fixed by changing user, pw = self.passwd.find_user_password(realm, host) to the user, pw = self.passwd.find_user_password(realm, req. get_full_url()) in the problem function ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&group_id=5470 From noreply at sourceforge.net Mon Dec 12 14:30:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 05:30:50 -0800 Subject: [ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char. Message-ID: Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-12-12 14:30 Message: Logged In: YES user_id=89016 With the Python 2.4.2 I get the following output both on Linux and Windows: open the file read the file close the file done This is totally independent of the type of line feeds in sample.txt or the length of the file (even or odd). > If it is a valid option (that should only be used > "Python internally" - not sure what that means) > then it should perform consistently regardless > of the number of characters in the file, should it not? unicode_internal just dumps the data bytes of the Unicode object. This means that (depending on the way Python is compiled) the length of a unicode_internal encoded byte string will always be a multiple of 2 or 4. So a byte string that has on odd number of bytes clearly is broken and decoding would have the right to complain about that. In 2.4.2 it doesn't, because it's not clear to the StreamReader API if there's more data available on subsequent calls to read() (and the last odd byte is silently dropped). BTW, the data read by your script is probably not what you might have expected. On a UCS-2 build the result is: u'\u2023\u7473\u7261\u3a74\u7320\u6d61\u6c70\u2e65\u7874\u0a74\u4552\u5553\u544c\u4f48\u5453\u763d\u7669\u6c61\u6964\u520a\u5345\u4c55\u5054\u524f\u3d54\u0a61\u4244\u585f\u4c4d\u2f3d\u6574\u7473\u612f\u7472\u6a2f\u7766\u632f\u6e6f\u6966\u2f67\u4244\u694c\u7473\u782e\u6c6d\u4c0a\u474f\u4843\u4345\u5f4b\u4749\u4f4e\u4552\u613d\u7472\u615f\u7463\u6f69\u736e\u742e\u7478' (or something similar depending on your line feeds). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:57 Message: Logged In: YES user_id=1188172 I'd suggest unicode_internal to be removed from the docs. ---------------------------------------------------------------------- Comment By: superwesman (superwesman) Date: 2005-12-10 00:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() should complain. If it is valid, it should perform consistently, IMHO. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 23:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the Python internal Unicode encoding (unicode_internal) ? This is an encoding that is only used Python internally and should not be used for anything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 From noreply at sourceforge.net Mon Dec 12 14:39:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 05:39:02 -0800 Subject: [ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char. Message-ID: Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-12 14:39 Message: Logged In: YES user_id=38388 Closing this bug report as "won't fix" (even though SF seems to have removed this option from the tracker, or at least I don't see it in Firefox). Removing "unicode_internal" from the docs is not an option: this is a valid encoding, albeit one that depends on the way Python is built. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-12 14:30 Message: Logged In: YES user_id=89016 With the Python 2.4.2 I get the following output both on Linux and Windows: open the file read the file close the file done This is totally independent of the type of line feeds in sample.txt or the length of the file (even or odd). > If it is a valid option (that should only be used > "Python internally" - not sure what that means) > then it should perform consistently regardless > of the number of characters in the file, should it not? unicode_internal just dumps the data bytes of the Unicode object. This means that (depending on the way Python is compiled) the length of a unicode_internal encoded byte string will always be a multiple of 2 or 4. So a byte string that has on odd number of bytes clearly is broken and decoding would have the right to complain about that. In 2.4.2 it doesn't, because it's not clear to the StreamReader API if there's more data available on subsequent calls to read() (and the last odd byte is silently dropped). BTW, the data read by your script is probably not what you might have expected. On a UCS-2 build the result is: u'\u2023\u7473\u7261\u3a74\u7320\u6d61\u6c70\u2e65\u7874\u0a74\u4552\u5553\u544c\u4f48\u5453\u763d\u7669\u6c61\u6964\u520a\u5345\u4c55\u5054\u524f\u3d54\u0a61\u4244\u585f\u4c4d\u2f3d\u6574\u7473\u612f\u7472\u6a2f\u7766\u632f\u6e6f\u6966\u2f67\u4244\u694c\u7473\u782e\u6c6d\u4c0a\u474f\u4843\u4345\u5f4b\u4749\u4f4e\u4552\u613d\u7472\u615f\u7463\u6f69\u736e\u742e\u7478' (or something similar depending on your line feeds). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:57 Message: Logged In: YES user_id=1188172 I'd suggest unicode_internal to be removed from the docs. ---------------------------------------------------------------------- Comment By: superwesman (superwesman) Date: 2005-12-10 00:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() should complain. If it is valid, it should perform consistently, IMHO. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 23:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the Python internal Unicode encoding (unicode_internal) ? This is an encoding that is only used Python internally and should not be used for anything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 From noreply at sourceforge.net Mon Dec 12 15:24:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 06:24:17 -0800 Subject: [ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file Message-ID: Bugs item #1378755, was opened at 2005-12-12 15:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Didrik Pinte (dpinte) Assigned to: Nobody/Anonymous (nobody) Summary: logging : fileConfig does not check existance of the file Initial Comment: Hi, The fileConfig method from the logging.config module does not check for the existance of the config file before trying to load it. Worst, if the file does not exist, the exception is totally unrelated to the file. Example : did at geru-itea:~/$ python Python 2.3.5 (#2, Nov 20 2005, 16:40:39) [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import config >>> config.fileConfig('') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/logging/config.py", line 68, in fileConfig flist = cp.get("formatters", "keys") File "/usr/lib/python2.3/ConfigParser.py", line 505, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: 'formatters' It is really important that the exception is correctly reported. In fact, the problem seems to be here : /usr/lib/python2.3/ConfigParser.py, line 258 for filename in filenames: try: fp = open(filename) except IOError: continue self._read(fp, filename) The documentation of the read method says "Files that cannot be opened are silently ignored;". The behaviour of logging.config.fileConfig is highly related to the user actions. He must be informed of the fact that the logging system have not opened its file. I will provide a very basic path : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.file(fname)): raise IOError('Provided filename is not existing') ------------------------------------------------- Didrik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 From noreply at sourceforge.net Mon Dec 12 15:25:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 06:25:38 -0800 Subject: [ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file Message-ID: Bugs item #1378755, was opened at 2005-12-12 15:24 Message generated for change (Comment added) made by dpinte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Didrik Pinte (dpinte) Assigned to: Nobody/Anonymous (nobody) Summary: logging : fileConfig does not check existance of the file Initial Comment: Hi, The fileConfig method from the logging.config module does not check for the existance of the config file before trying to load it. Worst, if the file does not exist, the exception is totally unrelated to the file. Example : did at geru-itea:~/$ python Python 2.3.5 (#2, Nov 20 2005, 16:40:39) [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import config >>> config.fileConfig('') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/logging/config.py", line 68, in fileConfig flist = cp.get("formatters", "keys") File "/usr/lib/python2.3/ConfigParser.py", line 505, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: 'formatters' It is really important that the exception is correctly reported. In fact, the problem seems to be here : /usr/lib/python2.3/ConfigParser.py, line 258 for filename in filenames: try: fp = open(filename) except IOError: continue self._read(fp, filename) The documentation of the read method says "Files that cannot be opened are silently ignored;". The behaviour of logging.config.fileConfig is highly related to the user actions. He must be informed of the fact that the logging system have not opened its file. I will provide a very basic path : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.file(fname)): raise IOError('Provided filename is not existing') ------------------------------------------------- Didrik ---------------------------------------------------------------------- >Comment By: Didrik Pinte (dpinte) Date: 2005-12-12 15:25 Message: Logged In: YES user_id=970259 i've reported it for Python 2.4 but I reproduced it on Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 From noreply at sourceforge.net Mon Dec 12 15:26:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 06:26:10 -0800 Subject: [ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file Message-ID: Bugs item #1378755, was opened at 2005-12-12 15:24 Message generated for change (Settings changed) made by dpinte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Didrik Pinte (dpinte) Assigned to: Nobody/Anonymous (nobody) Summary: logging : fileConfig does not check existance of the file Initial Comment: Hi, The fileConfig method from the logging.config module does not check for the existance of the config file before trying to load it. Worst, if the file does not exist, the exception is totally unrelated to the file. Example : did at geru-itea:~/$ python Python 2.3.5 (#2, Nov 20 2005, 16:40:39) [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import config >>> config.fileConfig('') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/logging/config.py", line 68, in fileConfig flist = cp.get("formatters", "keys") File "/usr/lib/python2.3/ConfigParser.py", line 505, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: 'formatters' It is really important that the exception is correctly reported. In fact, the problem seems to be here : /usr/lib/python2.3/ConfigParser.py, line 258 for filename in filenames: try: fp = open(filename) except IOError: continue self._read(fp, filename) The documentation of the read method says "Files that cannot be opened are silently ignored;". The behaviour of logging.config.fileConfig is highly related to the user actions. He must be informed of the fact that the logging system have not opened its file. I will provide a very basic path : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.file(fname)): raise IOError('Provided filename is not existing') ------------------------------------------------- Didrik ---------------------------------------------------------------------- Comment By: Didrik Pinte (dpinte) Date: 2005-12-12 15:25 Message: Logged In: YES user_id=970259 i've reported it for Python 2.4 but I reproduced it on Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 From noreply at sourceforge.net Mon Dec 12 15:27:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 06:27:37 -0800 Subject: [ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file Message-ID: Bugs item #1378755, was opened at 2005-12-12 15:24 Message generated for change (Comment added) made by dpinte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Didrik Pinte (dpinte) Assigned to: Nobody/Anonymous (nobody) Summary: logging : fileConfig does not check existance of the file Initial Comment: Hi, The fileConfig method from the logging.config module does not check for the existance of the config file before trying to load it. Worst, if the file does not exist, the exception is totally unrelated to the file. Example : did at geru-itea:~/$ python Python 2.3.5 (#2, Nov 20 2005, 16:40:39) [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import config >>> config.fileConfig('') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/logging/config.py", line 68, in fileConfig flist = cp.get("formatters", "keys") File "/usr/lib/python2.3/ConfigParser.py", line 505, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: 'formatters' It is really important that the exception is correctly reported. In fact, the problem seems to be here : /usr/lib/python2.3/ConfigParser.py, line 258 for filename in filenames: try: fp = open(filename) except IOError: continue self._read(fp, filename) The documentation of the read method says "Files that cannot be opened are silently ignored;". The behaviour of logging.config.fileConfig is highly related to the user actions. He must be informed of the fact that the logging system have not opened its file. I will provide a very basic path : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.file(fname)): raise IOError('Provided filename is not existing') ------------------------------------------------- Didrik ---------------------------------------------------------------------- >Comment By: Didrik Pinte (dpinte) Date: 2005-12-12 15:27 Message: Logged In: YES user_id=970259 Oups, the patch should be the following : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.isfile(fname)): raise IOError('Provided filename is not existing') ---------------------------------------------------------------------- Comment By: Didrik Pinte (dpinte) Date: 2005-12-12 15:25 Message: Logged In: YES user_id=970259 i've reported it for Python 2.4 but I reproduced it on Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 From noreply at sourceforge.net Mon Dec 12 15:35:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 06:35:38 -0800 Subject: [ python-Bugs-1378022 ] source utf8 Message-ID: Bugs item #1378022, was opened at 2005-12-11 07:48 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: zhao (ibear) Assigned to: Nobody/Anonymous (nobody) Summary: source utf8 Initial Comment: winxp sp2(chinese or japanese) and python 2.42 i have created a utf8 source file with BOM_UTF8 if i add a '#coding: utf8' at first line and run it, the python interpreter will crash ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-12-12 15:35 Message: Logged In: YES user_id=89016 The following patch (pythonrun.diff) should fix the segfault. However UTF-8 files with a leading BOM currently aren't supported. There's a pending patch (http://bugs.python.org/1177307) that adds a utf-8-sig codec for that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 From noreply at sourceforge.net Mon Dec 12 15:39:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 06:39:31 -0800 Subject: [ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char. Message-ID: Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-12-12 15:39 Message: Logged In: YES user_id=89016 Strange, Firefox seems to have some layout problems. The "Resolution" box has moved way to the right. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-12 14:39 Message: Logged In: YES user_id=38388 Closing this bug report as "won't fix" (even though SF seems to have removed this option from the tracker, or at least I don't see it in Firefox). Removing "unicode_internal" from the docs is not an option: this is a valid encoding, albeit one that depends on the way Python is built. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-12 14:30 Message: Logged In: YES user_id=89016 With the Python 2.4.2 I get the following output both on Linux and Windows: open the file read the file close the file done This is totally independent of the type of line feeds in sample.txt or the length of the file (even or odd). > If it is a valid option (that should only be used > "Python internally" - not sure what that means) > then it should perform consistently regardless > of the number of characters in the file, should it not? unicode_internal just dumps the data bytes of the Unicode object. This means that (depending on the way Python is compiled) the length of a unicode_internal encoded byte string will always be a multiple of 2 or 4. So a byte string that has on odd number of bytes clearly is broken and decoding would have the right to complain about that. In 2.4.2 it doesn't, because it's not clear to the StreamReader API if there's more data available on subsequent calls to read() (and the last odd byte is silently dropped). BTW, the data read by your script is probably not what you might have expected. On a UCS-2 build the result is: u'\u2023\u7473\u7261\u3a74\u7320\u6d61\u6c70\u2e65\u7874\u0a74\u4552\u5553\u544c\u4f48\u5453\u763d\u7669\u6c61\u6964\u520a\u5345\u4c55\u5054\u524f\u3d54\u0a61\u4244\u585f\u4c4d\u2f3d\u6574\u7473\u612f\u7472\u6a2f\u7766\u632f\u6e6f\u6966\u2f67\u4244\u694c\u7473\u782e\u6c6d\u4c0a\u474f\u4843\u4345\u5f4b\u4749\u4f4e\u4552\u613d\u7472\u615f\u7463\u6f69\u736e\u742e\u7478' (or something similar depending on your line feeds). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:57 Message: Logged In: YES user_id=1188172 I'd suggest unicode_internal to be removed from the docs. ---------------------------------------------------------------------- Comment By: superwesman (superwesman) Date: 2005-12-10 00:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() should complain. If it is valid, it should perform consistently, IMHO. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 23:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the Python internal Unicode encoding (unicode_internal) ? This is an encoding that is only used Python internally and should not be used for anything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 From noreply at sourceforge.net Mon Dec 12 16:53:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 07:53:45 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 17:03 Message generated for change (Comment added) made by ken668 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ken668 (ken668) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: ken668 (ken668) Date: 2005-12-12 07:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Mon Dec 12 16:59:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 07:59:33 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 17:03 Message generated for change (Comment added) made by ken668 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ken668 (ken668) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: ken668 (ken668) Date: 2005-12-12 07:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Mon Dec 12 17:00:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 08:00:00 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 17:03 Message generated for change (Comment added) made by ken668 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ken668 (ken668) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: ken668 (ken668) Date: 2005-12-12 08:00 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Mon Dec 12 18:44:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 09:44:29 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 20:03 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ken668 (ken668) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 11:00 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 10:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 10:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 15:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Tue Dec 13 04:14:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 19:14:46 -0800 Subject: [ python-Bugs-1379209 ] socket.recv(OOB) raises exception on closed socket Message-ID: Bugs item #1379209, was opened at 2005-12-12 22:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379209&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: socket.recv(OOB) raises exception on closed socket Initial Comment: frame:pyClient$ python Python 2.4.1 (#1, Aug 16 2005, 20:11:22) [GCC 3.4.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> ^D frame:pyClient$ uname -a SunOS frame 5.8 Generic_108528-27 sun4u sparc If you try to read out-of-band data on a closed socket, the recv() call raises socket.error, signaling "invalid argument". This seems wrong. Doing a normal (in-band) recv() on a closed socket returns an empty string; trying to read OOB data should do the same thing. At worst, it should raise a more specific error. I'm guessing this exception is reflecting an errno of EBADF. A more specific error would at least make it clear that it's the first argument to recv() which was bad, not the second. frame:pyClient$ cat oob.py #!/usr/bin/env python import socket s = socket.socket() s.connect (("localhost", 13)) # 13 = daytime print "==> ", `s.recv(1024)` print "OOB: ", `s.recv (1024, socket.MSG_OOB)` frame:pyClient$ ./oob.py ==> 'Mon Dec 12 22:00:29 2005\n\r' OOB: Traceback (most recent call last): File "./oob.py", line 8, in ? print "OOB: ", `s.recv (1024, socket.MSG_OOB)` socket.error: (22, 'Invalid argument') frame:pyClient$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379209&group_id=5470 From noreply at sourceforge.net Tue Dec 13 11:35:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 02:35:49 -0800 Subject: [ python-Bugs-1379393 ] StreamReader.readline doesn't advance on decode errors Message-ID: Bugs item #1379393, was opened at 2005-12-13 02: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=1379393&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: StreamReader.readline doesn't advance on decode errors Initial Comment: In previous versions of python, when there was a unicode decode error, StreamReader.readline() would advance to the next line. In the current version(2.4.2 and trunk), it doesn't. Testing under Linux AMD64 (Ubuntu 5.10) Attaching an example script. In python2.3 it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 2: unexpected code byte error: 'utf8' codec can't decode byte 0x81 in position 2: unexpected code byte all done In python2.4 and trunk it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte [repeats forever] Maybe this isn't actually supposed to work (the docs don't mention what should happen with strict error checking..), but it would be nice, given the alternatives: 1. use errors='replace' and then search the result for the replacement character. (ick) 2. define a custom error handler similar to ignore or replace, that also sets some flag. (slightly less ick, but more work.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470 From noreply at sourceforge.net Tue Dec 13 12:09:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 03:09:30 -0800 Subject: [ python-Bugs-1379416 ] email.Header encode() unicode P2.3xP2.4 Message-ID: Bugs item #1379416, was opened at 2005-12-13 12: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=1379416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Novak (xnovakj) Assigned to: Nobody/Anonymous (nobody) Summary: email.Header encode() unicode P2.3xP2.4 Initial Comment: Python: 2.4 Module: email.Header Method: encode() In some cases returns unicode (example on line 5) 1>> from email.Header import Header 2>> Header(unicode('abc??','iso-8859-2'),'utf-8').encode() '=?utf-8?b?YWJjw6E=?=' 3>> Header('abc','utf-8').encode() '=?utf-8?q?abc?=' 4>> Header(u'abc','utf-8').encode() 'abc' ??? 5>> Header('abc','iso-8859-2').encode() u'=?iso-8859-2?q?abc?=' (P2.4) 6>> Header('abc','iso-8859-2').encode() '=?iso-8859-2?q?abc?=' (P2.3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379416&group_id=5470 From noreply at sourceforge.net Tue Dec 13 16:13:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 07:13:32 -0800 Subject: [ python-Feature Requests-1379573 ] python executable optionally should search script on PATH Message-ID: Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 From noreply at sourceforge.net Tue Dec 13 21:22:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 12:22:25 -0800 Subject: [ python-Bugs-1379804 ] HP-UX thread stack size needs to be increased Message-ID: Bugs item #1379804, was opened at 2005-12-13 20: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=1379804&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX thread stack size needs to be increased Initial Comment: On HP-UX the default thread stack size is "insufficient" and probably needs to be increased if threads are performing any heavy tasks. Obviously, the ideal size depends on you application but I find that THREAD_STACK_SIZE=0x50000 works well for me. Using the default thread stack size my multi-threading tests were failing with a corrupt stack sometimes and this stack trace other times: #0 0x79db8c0c in _isspace+0x2d8 () from /usr/lib/libnss_dns.1 #1 0x7aff62c4 in nss_search+0x28c () from /usr/lib/libc.2 #2 0x7af4d320 in __gethostbyname_r+0x140 () from /usr/lib/libc.2 #3 0x7af4d4bc in gethostbyname+0x94 () from /usr/lib/libc.2 #4 here, I am calling: gethostbyname("localhost") [cut] #23 0x7a8c49ac in OpSession::begin+0x1c0 () from /space/bdoyle/hprisc/lib/oopython.sl #24 0x7aa42660 in PyCFunction_Call+0xc8 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl [cut] #38 0x7aabbda0 in PyEval_CallObjectWithKeywords+0x1c4 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl #39 0x7ab17e8c in t_bootstrap+0xa0 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl #40 0x7ab6400c in __pthread_body+0x44 () from /usr/lib/libpthread.1 #41 0x7ab6e29c in __pthread_start+0x14 () from /usr/lib/libpthread.1 I tested both Python 2.3.4 and 2.4.2 and increased stack size solves the probem on both. I suggest that a note be added to the Python README under the HP-UX section. The note should suggest that the "BASECFLAGS" environment variable be set to include "-DTHREAD_STACK_SIZE=0x50000" prior to running configure. I dont know that 0x50000 is really the ideal stack size..... Blade. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470 From noreply at sourceforge.net Wed Dec 14 01:20:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 16:20:38 -0800 Subject: [ python-Bugs-1379984 ] HP-UX: Can't shl_load() a library containing Thread Local Message-ID: Bugs item #1379984, was opened at 2005-12-14 00: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=1379984&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: Can't shl_load() a library containing Thread Local Initial Comment: HP-UX runtime loader does not support dynamic load of shared libraries that contain (TLS) thread local storage. As a result, when attempting to import modules that contain TLS the following error is reported: "/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage" This problem was discussed previously on the python.org mail list: http://mail.python.org/pipermail/python-list/2003-May/164024.html There is another option: Use LD_PRELOAD environment variable to cuase the runtime loader to 'pre-load' the pthreads library (and dependancies of the pthread library). See the dld.sl(5) man page for more info on LD_PRELOAD. But, I think a 5th option is ideal. If libpthread.sl (and the dependancies of libpthread) are linked into the python executable at build time then all of these problems are avoided. I suggest that the HP-UX (includes hp-ux on ia64) build process be modified so that libpthead (and depends) are linked in. Or, at least, make a note of this problem/solution in the HP-UX section of the README file distributed with python source. Here is the process I use to work around the TLS problem: HP-UX: bash$ BASECFLAGS="-DTHREAD_STACK_SIZE=0x50000"; export BASECFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs='-lpthread -lstd_v2 -lCsup_v2 -lcl' bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install HP-UX on ia64: bash$ CC=cc; export CC bash$ CXX=aCC; export CXX bash$ BASECFLAGS="+DD64 -DTHREAD_STACK_SIZE=0x50000"; export BASECFLAGS bash$ LDFLAGS="+DD64"; export LDFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs="-lpthread -lCsup -lstd_v2 -lunwind" bash$ unset CC bash$ unset CXX bash$ unset BASECFLAGS bash$ unset LDFLAGS bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&group_id=5470 From noreply at sourceforge.net Wed Dec 14 01:47:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 16:47:27 -0800 Subject: [ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken Message-ID: Bugs item #1379994, was opened at 2005-12-13 19:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Mc Mahon (markmcmahon) Assigned to: M.-A. Lemburg (lemburg) Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken Initial Comment: In Python 2.4.2 and Python 2.4.1 (Windows XP) >>> "\t\t".encode("string_escape") '\t\\t' >>> "\t\t".encode("unicode_escape") '\t\t' >>> "\t\t".encode("raw_unicode_escape") '\t\t' >>> u"\t\t".encode("unicode_escape") '\t\t' >>> u"\t\t".encode("raw_unicode_escape") '\t\t' I would have expected all to produce the same result. Also round-tripping with the encoding doesn't seem to work: >>> "\t\t".encode('string_escape').decode('string_escape') '\t\t' >>> u"\t\t".encode('unicode_escape').decode('unicode_escape') u'\t\t' Thanks Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 From noreply at sourceforge.net Wed Dec 14 02:41:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 17:41:53 -0800 Subject: [ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken Message-ID: Bugs item #1379994, was opened at 2005-12-14 09:47 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Mc Mahon (markmcmahon) Assigned to: M.-A. Lemburg (lemburg) Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken Initial Comment: In Python 2.4.2 and Python 2.4.1 (Windows XP) >>> "\t\t".encode("string_escape") '\t\\t' >>> "\t\t".encode("unicode_escape") '\t\t' >>> "\t\t".encode("raw_unicode_escape") '\t\t' >>> u"\t\t".encode("unicode_escape") '\t\t' >>> u"\t\t".encode("raw_unicode_escape") '\t\t' I would have expected all to produce the same result. Also round-tripping with the encoding doesn't seem to work: >>> "\t\t".encode('string_escape').decode('string_escape') '\t\t' >>> u"\t\t".encode('unicode_escape').decode('unicode_escape') u'\t\t' Thanks Mark ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-14 10:41 Message: Logged In: YES user_id=55188 Attached a patch. It looks like a simple typo. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 From noreply at sourceforge.net Wed Dec 14 07:06:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 22:06:40 -0800 Subject: [ python-Bugs-1369116 ] freeze idle-python2.3 on my debia n sarge Message-ID: Bugs item #1369116, was opened at 2005-11-29 07:37 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Santonja (gsantonja) Assigned to: Nobody/Anonymous (nobody) Summary: freeze idle-python2.3 on my debia n sarge Initial Comment: When I press space bar continusly idle-python task have a random freeze 8/10 times before the caracter 300. I must kill the task and restart This arrive frequently during my development. Architecture : idle python 2.3 Debian sarge without modification XFCE 4.0 Nvidia driver hp nx9105 I have try to made again the bug on other architecture but i don't have success on windows XP and debion in virtual pc. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-12-14 01:06 Message: Logged In: YES user_id=149084 What happens when you start IDLE with no subprocess (use the -n switch)? You say it happens frequently in development. I assume that you mean that in normal use after typing for some time IDLE will freeze. Correct? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 From noreply at sourceforge.net Wed Dec 14 07:10:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 22:10:43 -0800 Subject: [ python-Bugs-1378305 ] Import value 1e400 from pyc fails Message-ID: Bugs item #1378305, was opened at 2005-12-11 13:09 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Guenter Jantzen (gjantzen) Assigned to: Nobody/Anonymous (nobody) Summary: Import value 1e400 from pyc fails Initial Comment: ------------------------------------------- #file: bug.py #sys.version_info (2, 4, 2, 'final', 0) #Platform is Windows XP import sys, bug infinity = 1e400 if __name__ == "__main__": import bug print "Infinity is", bug.infinity ------------------------------------------ This code behaves correct using bug.py - when bug.pyc is not up to date / not exists: Infinity is 1.#INF and behaves wrong using bug.pyc - when bug.pyc is up to date: Infinity is 1.0 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-13 22:10 Message: Logged In: YES user_id=341410 This is a known bug with Python and floating point infinity literals. You can use: infinity = 1e155 * 1e155 I believe this is fixed in the latest Python 2.5 SVN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 From noreply at sourceforge.net Wed Dec 14 07:16:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 22:16:49 -0800 Subject: [ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed Message-ID: Bugs item #1370380, was opened at 2005-11-30 13:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-13 22:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 From noreply at sourceforge.net Wed Dec 14 13:02:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 04:02:22 -0800 Subject: [ python-Bugs-1369116 ] freeze idle-python2.3 on my debia n sarge Message-ID: Bugs item #1369116, was opened at 2005-11-29 13:37 Message generated for change (Comment added) made by gsantonja You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Santonja (gsantonja) Assigned to: Nobody/Anonymous (nobody) Summary: freeze idle-python2.3 on my debia n sarge Initial Comment: When I press space bar continusly idle-python task have a random freeze 8/10 times before the caracter 300. I must kill the task and restart This arrive frequently during my development. Architecture : idle python 2.3 Debian sarge without modification XFCE 4.0 Nvidia driver hp nx9105 I have try to made again the bug on other architecture but i don't have success on windows XP and debion in virtual pc. ---------------------------------------------------------------------- >Comment By: Gabriel Santonja (gsantonja) Date: 2005-12-14 13:02 Message: Logged In: YES user_id=1392073 Hello, > What happens when you start IDLE with no subprocess > (use the > -n switch)? The same thing : freeze 4 time on 5 test. > time IDLE will freeze. Correct? yes. idle freeze sp??cially when i use the space caracters for indentation. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-12-14 07:06 Message: Logged In: YES user_id=149084 What happens when you start IDLE with no subprocess (use the -n switch)? You say it happens frequently in development. I assume that you mean that in normal use after typing for some time IDLE will freeze. Correct? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 From noreply at sourceforge.net Wed Dec 14 15:41:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 06:41:50 -0800 Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro Message-ID: Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:41 Message: Logged In: YES user_id=4771 I'm getting confused. First note that the problem I mentioned about extra_ivars() triggering an assert() can only occur at start-up. Indeed, PyType_Ready() copies the tp_base->tp_basicsize if the subtype's tp_basicsize is 0. So we can probably ignore the problem -- no extra_ivars() call would trigger the assert after start-up. The check that your patch adds is that solid_base(A) must be a superclass of solid_base(T) for each A in the mro of T. For built-in mros, the A's are exactly the superclasses of T. So we have to prove [*]: if A is a superclass of T, then solid_base(A) is a superclass of solid_base(T). Irrespective of what extra_ivars() does, solid_base(T) is either exactly T, or solid_base(T->tp_base). Moreover, when a type T is created with immediate bases B1...Bn, we check that all solid_bases of B1...Bn form a linear order (i.e. are subclasses of each other), and we set T->tp_base to the first Bi such that solid_base(Bi) is a subclass of all the other solid_base(Bj). Let's approach [*] above by induction on the set of types in which A and T are chosen. This set of types can be ordered by creation time: T1, T2, T3, ... where classes with a higher index can only inherit from classes with lower indices. Assume that [*] holds if A and T are chosen among T1...Tn-1. Let's prove it if A and/or T can also be Tn. The only non-trivial case is if A is a strict superclass of T=Tn. As above, let write B1...Bn for the immediate bases of T, with T->tp_base=Bi. Pick j such that A is a superclass of Bj. By induction solid_base(A) is a superclass of solid_base(Bj) which is a superclass of solid_base(Bi=T->tp_base). Now solid_base(T) is either T or solid_base(Bi). In both cases, solid_base(T) is a subclass of solid_base(A). This concludes the proof -- or I am missing something :-) In other words, I don't think the patch can break anything, so it should definitely go in. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-15 13:22 Message: Logged In: YES user_id=6656 Please see the attached PDF for a proof of ... well, something in the area. I think this is what typeobject.c should be doing and what it's *trying* to do. I'm less confident that this is what it's actually doing (particularly wrt the subclassing two subclasses of str thing). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-14 11:41 Message: Logged In: YES user_id=6656 Well, emprically that can't happen because the patch passes test_descr, and far sillier things happen in that file than in real life. More theoretically... I'll think about it :) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-03-14 11:25 Message: Logged In: YES user_id=4771 I tried to convince myself that this check always accepts the default mro, but there are more implicit assumptions around than I can handle in a quick review... Instead, I modified the patch so that a debug build of Python always does the check in mro_internal(). This results in a shallow problem: the basestring type has tp_basicsize==0, which makes the computation of its solid_base trigger an assertion in extra_ivars(). If I hack around this problem, then I cannot quickly find an example of built-in mro that triggers a TypeError, but it doesn't mean there isn't one... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-06 18:47 Message: Logged In: YES user_id=6656 I think the attached fixes all this. What it does: check the return value of PySequence_Tuple (duh). Check that the returned sequence contains only types or old-style classes. Checks that the solid_base of each type in the returned sequence is a supertype of the solid_base of type being built. Adds a few tests. The error messages are a bit inscrutable. I find it hard to care. Assigning to Armin for the first look. Might want to get Guido to look at it too. When Armin and I talked about this on IRC we found a few oddities in the general area, but I don't know if it's worth opening a new bug report for them... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-03 09:50 Message: Logged In: YES user_id=6656 Certainly some more checking of what the user-defined MRO contains would be good -- check the attached, which dumps core at class definition time... ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-03-03 09:34 Message: Logged In: YES user_id=4771 The PyXxx_Check() macros are #defined with PyObject_TypeCheck(). Should we change all these #defines to use a new PyObject_LayoutCheck() or something, and document to C extension writers that they should also switch to the new function? More generally, should we review *all* usages of PyObject_TypeCheck() and decide if they really meant that or PyObject_LayoutCheck()? Do we care about types that are solid subclasses of 'int' but don't have it in their MRO? Should we just forget the whole idea and sanity-check the user-defined mro, which after all would just add another strange undocumented condition to typeobject.c? :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-02 20:11 Message: Logged In: YES user_id=6656 Hmm, yeah, that works. It wasn't totally clear to me that the user couldn't maliciously influence tp_base, but I don't think they can... A helper function is presumably in order, unless PyType_IsSubtype should be changed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-03-02 17:03 Message: Logged In: YES user_id=4771 To solve the problem, as hinted in the title of this tracker, I think that PyXxx_Check() should simply not trust any mro. What PyInt_Check() really means at the C level is to check if an object memory layout is compatible with PyIntObject. This is easy to figure out by walking the "solid base" chain, tp_base. As a side note, PyPy gives the same error as Python 2.2. However, both in PyPy and in Python 2.2, you can still build an instance of the strange class X as follows: >>> x = object.__new__(X) Still, all the methods of x are resolved via the dict type. In PyPy we get a clean TypeError because the methods thus found don't apply to non-dict objects. In Python 2.2 you can crash the interpreter just as in more recent Python releases, e.g. with x[5]=6. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-01 20:18 Message: Logged In: YES user_id=6656 I wonder if Guido owes Armin a beer (read typeobject.c around line 5230). Well, not really, but it's that code that is making the difference. However, reversing the order of dict and object is sufficient to make 2.2 crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting code chopped out which gives the error jelper observes on the original). I wonder what to do about this. Removing the ability to customize the mro from user code is one obvious approach -- I don't know how much code uses this feature though. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-03-01 19:15 Message: Logged In: YES user_id=2772 Not sure if this is relevant, but the example given didn't crash 2.2: $ python2.2 bug.py Traceback (most recent call last): File "bug.py", line 9, in ? x = X() TypeError: dict.__new__(X) is not safe, use object.__new__() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 From noreply at sourceforge.net Wed Dec 14 15:49:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 06:49:20 -0800 Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness Message-ID: Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-25 08:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 From noreply at sourceforge.net Wed Dec 14 15:57:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 06:57:37 -0800 Subject: [ python-Bugs-1174712 ] subclassing ModuleType and another built-in type Message-ID: Bugs item #1174712, was opened at 2005-04-01 09:22 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: subclassing ModuleType and another built-in type Initial Comment: class X(types.ModuleType, str): pass X('name') -> segfault This buggy subclassing goes through typeobject.c's checks because PyModuleObject looks exactly like a user-defined subclass of 'object': it has a PyObject_HEAD followed only by the dict, as specified by tp_dictoffset. A fix would be to forbid any subclassing to move the tp_dictoffset of a non-heap type. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:57 Message: Logged In: YES user_id=4771 The objection to the proposed fix is not valid in light of the bug #1303614, which gives a general way to abuse subclassing to allow the __dict__ of an instance to be assigned to and deleted, even when it should not be allowed. So I wouldn't worry too much about the case I pointed up, because it should be fixed together with #1303614 (though I don't really know how). For now I would be happy with just checking that subclassing a non-heap type doesn't move the dict within the structure. The same remark probably applies to the weakref field. Both cases could be fixed by being more careful in typeobject.c:extra_ivars(): PyModule_Type should be considered to have extra_ivars() when compared to PyBaseObject_Type. This could be achieved by skipping the "t_size -= ..." part if "type" is not a heap type. Indeed, for non-heap types we should not try to consider that an extra dict or weakref slot is not important, because the C code probably accesses this extra slot directly, as in the case of moduleobject.c. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-03 13:39 Message: Logged In: YES user_id=6656 > This might point to the need for cleaning up typeobject.c's > darker corners... No kidding. Maybe Samuele, you and I can gang up on Guido at EuroPython (is he sprinting? Perhaps we should ask). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-02 12:27 Message: Logged In: YES user_id=4771 The proposed fix is not good enough. If another built-in C type similar to PyModuleObject is defined (say by a C extension module), then it would become possible to subclass both this new type and ModuleType. This might lead to unwanted behavior if e.g. one parent class allows rebinding __dict__ and the other not (and crashes if __dict__ is rebound). This might point to the need for cleaning up typeobject.c's darker corners... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470 From noreply at sourceforge.net Wed Dec 14 16:32:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 07:32:53 -0800 Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness Message-ID: Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 15:32 Message: Logged In: YES user_id=4771 A proposed fix for the later crash: the __dict__ descriptor of user-defined classes should verify if there is another __dict__ descriptor along the solid path of the type (i.e. following "tp_base" pointers). If so, it should delegate to it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-25 08:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 From noreply at sourceforge.net Wed Dec 14 16:36:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 07:36:05 -0800 Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness Message-ID: Bugs item #1303614, was opened at 2005-09-25 00:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-14 15:36 Message: Logged In: YES user_id=6656 Yikes! ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 15:32 Message: Logged In: YES user_id=4771 A proposed fix for the later crash: the __dict__ descriptor of user-defined classes should verify if there is another __dict__ descriptor along the solid path of the type (i.e. following "tp_base" pointers). If so, it should delegate to it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-25 09:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 From noreply at sourceforge.net Wed Dec 14 23:59:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 14:59:08 -0800 Subject: [ python-Bugs-1353269 ] poplib.POP3_SSL() class incompatible with socket.timeout Message-ID: Bugs item #1353269, was opened at 2005-11-10 17:34 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: poplib.POP3_SSL() class incompatible with socket.timeout Initial Comment: If you call socket.setdefaulttimeout() to enable timeout mode, then create a POP3-over-SSL connection by instantiating a poplib.POP3_SSL() object, the resulting connection can hang because the underlying socket.ssl() object doesn't work when timeouts are enabled. If, after creating the POP3_SSL object, you call object.conn.sock.setblocking(1), the hangs will not happen. This is exactly the same bug as happened with IMAP SSL connections, as I reported in bug #977680. The Python documentation still does not mention that socket SSL support is not compatible with socket timeout support. ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-12-14 23:59 Message: Logged In: YES user_id=139606 It's just broken in _ssl.c. In PySSL_SSLread() there is: sockstate = check_socket_and_wait_for_timeout(self->Socket, 0); It hangs here because that function waits for new data on the socket but SSL layer could already read that data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 From noreply at sourceforge.net Thu Dec 15 00:31:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 15:31:44 -0800 Subject: [ python-Bugs-1353269 ] poplib.POP3_SSL() class incompatible with socket.timeout Message-ID: Bugs item #1353269, was opened at 2005-11-10 17:34 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: poplib.POP3_SSL() class incompatible with socket.timeout Initial Comment: If you call socket.setdefaulttimeout() to enable timeout mode, then create a POP3-over-SSL connection by instantiating a poplib.POP3_SSL() object, the resulting connection can hang because the underlying socket.ssl() object doesn't work when timeouts are enabled. If, after creating the POP3_SSL object, you call object.conn.sock.setblocking(1), the hangs will not happen. This is exactly the same bug as happened with IMAP SSL connections, as I reported in bug #977680. The Python documentation still does not mention that socket SSL support is not compatible with socket timeout support. ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-12-15 00:31 Message: Logged In: YES user_id=139606 btw. please test this patch: https://sourceforge.net/tracker /index.php?func=detail&aid=1380952&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-12-14 23:59 Message: Logged In: YES user_id=139606 It's just broken in _ssl.c. In PySSL_SSLread() there is: sockstate = check_socket_and_wait_for_timeout(self->Socket, 0); It hangs here because that function waits for new data on the socket but SSL layer could already read that data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 From noreply at sourceforge.net Thu Dec 15 00:33:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 15:33:49 -0800 Subject: [ python-Bugs-1380970 ] split() description not fully accurate Message-ID: Bugs item #1380970, was opened at 2005-12-14 18:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: K.C. (kace) Assigned to: Nobody/Anonymous (nobody) Summary: split() description not fully accurate Initial Comment: The page http://docs.python.org/lib/string-methods.html reads, in part, "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." However, this is not the behaviour that I'm seeing. (Although, I should note that I'd find the described behaviour more desirable.) Example, >>> trow = '1586\tsome-int-name\tNODES: 111_222\n' >>> print trow 1234 some-int-name NODES: 111_222 >>> trow.split(None,2) ['1234', 'some-int-name', 'NODES: 111_222\n'] # end example. Notice that the trailing newline has not been stripped as the documentation said it should be. Thanks all. K.C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 From noreply at sourceforge.net Thu Dec 15 00:36:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 15:36:53 -0800 Subject: [ python-Bugs-1380970 ] split() description not fully accurate Message-ID: Bugs item #1380970, was opened at 2005-12-14 18:33 Message generated for change (Comment added) made by kace You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: K.C. (kace) Assigned to: Nobody/Anonymous (nobody) Summary: split() description not fully accurate Initial Comment: The page http://docs.python.org/lib/string-methods.html reads, in part, "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." However, this is not the behaviour that I'm seeing. (Although, I should note that I'd find the described behaviour more desirable.) Example, >>> trow = '1586\tsome-int-name\tNODES: 111_222\n' >>> print trow 1234 some-int-name NODES: 111_222 >>> trow.split(None,2) ['1234', 'some-int-name', 'NODES: 111_222\n'] # end example. Notice that the trailing newline has not been stripped as the documentation said it should be. Thanks all. K.C. ---------------------------------------------------------------------- >Comment By: K.C. (kace) Date: 2005-12-14 18:36 Message: Logged In: YES user_id=741142 Also, (oops) the example comes from the most recent version: $ python Python 2.4.2 (#2, Oct 4 2005, 13:57:10) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 From noreply at sourceforge.net Thu Dec 15 01:27:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 16:27:51 -0800 Subject: [ python-Bugs-1369116 ] freeze idle-python2.3 on my debia n sarge Message-ID: Bugs item #1369116, was opened at 2005-11-29 07:37 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Gabriel Santonja (gsantonja) >Assigned to: Kurt B. Kaiser (kbk) Summary: freeze idle-python2.3 on my debia n sarge Initial Comment: When I press space bar continusly idle-python task have a random freeze 8/10 times before the caracter 300. I must kill the task and restart This arrive frequently during my development. Architecture : idle python 2.3 Debian sarge without modification XFCE 4.0 Nvidia driver hp nx9105 I have try to made again the bug on other architecture but i don't have success on windows XP and debion in virtual pc. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-12-14 19:27 Message: Logged In: YES user_id=149084 Ok, this looks like a duplicate of Bug 1108992. It appears to be a Tcl bug or maybe a pthread bug. Refer to the gdb trace attached to that bug. There's nothing I can do in IDLE, which is pure Python. I suggest you make sure you are apt-get upgraded and if the problem persists, either try Python from Sid or submit a Debian bug. ---------------------------------------------------------------------- Comment By: Gabriel Santonja (gsantonja) Date: 2005-12-14 07:02 Message: Logged In: YES user_id=1392073 Hello, > What happens when you start IDLE with no subprocess > (use the > -n switch)? The same thing : freeze 4 time on 5 test. > time IDLE will freeze. Correct? yes. idle freeze sp??cially when i use the space caracters for indentation. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-12-14 01:06 Message: Logged In: YES user_id=149084 What happens when you start IDLE with no subprocess (use the -n switch)? You say it happens frequently in development. I assume that you mean that in normal use after typing for some time IDLE will freeze. Correct? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 From noreply at sourceforge.net Thu Dec 15 06:15:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 21:15:21 -0800 Subject: [ python-Bugs-1380970 ] split() description not fully accurate Message-ID: Bugs item #1380970, was opened at 2005-12-14 18:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: K.C. (kace) >Assigned to: Raymond Hettinger (rhettinger) Summary: split() description not fully accurate Initial Comment: The page http://docs.python.org/lib/string-methods.html reads, in part, "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." However, this is not the behaviour that I'm seeing. (Although, I should note that I'd find the described behaviour more desirable.) Example, >>> trow = '1586\tsome-int-name\tNODES: 111_222\n' >>> print trow 1234 some-int-name NODES: 111_222 >>> trow.split(None,2) ['1234', 'some-int-name', 'NODES: 111_222\n'] # end example. Notice that the trailing newline has not been stripped as the documentation said it should be. Thanks all. K.C. ---------------------------------------------------------------------- Comment By: K.C. (kace) Date: 2005-12-14 18:36 Message: Logged In: YES user_id=741142 Also, (oops) the example comes from the most recent version: $ python Python 2.4.2 (#2, Oct 4 2005, 13:57:10) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 From noreply at sourceforge.net Thu Dec 15 06:17:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 21:17:22 -0800 Subject: [ python-Bugs-1361643 ] textwrap.dedent() expands tabs Message-ID: Bugs item #1361643, was opened at 2005-11-19 14:02 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Steven Bethard (bediviere) Assigned to: Greg Ward (gward) Summary: textwrap.dedent() expands tabs Initial Comment: I'm not sure whether this is a documentation bug or a code bug, but textwrap.dedent() expands tabs (and AFAICT doesn't give the user any way of stopping this): py> def test(): ... x = ('abcd efgh\n' ... 'ijkl mnop\n') ... y = textwrap.dedent('''... abcd efgh ... ijkl mnop ... ''') ... return x, y ... py> test() ('abcd\tefgh\nijkl\tmnop\n', 'abcd efgh\nijkl mnop\n') Looking at the code, I can see the culprit is the first line: lines = text.expandtabs().split('\n') If this is the intended behavior, I think the first sentence in the documentation[1] should be replaced with: """ Replace all tabs in string with spaces as per str.expandtabs() and then remove any whitespace that can be uniformly removed from the left of every line in text. """ and (I guess this part is an RFE) textwrap.dedent() should gain an optional expandtabs= keyword argument to disable this behavior. If it's not the intended behavior, I'd love to see that .expandtabs() call removed. [1]http://docs.python.org/lib/module-textwrap.html ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-20 01:04 Message: Logged In: YES user_id=80475 Suggested code: import re as _re _emptylines_with_spaces = _re.compile('(?m)^[ \t]+$') _prefixes_on_nonempty_lines = _re.compile('(?m)(^[ \t]*)(?:[^ \t\n]+)') def dedent(text): text = _emptylines_with_spaces.sub('', text) prefixes = _prefixes_on_nonempty_lines.findall(text) margin = min(prefixes or ['']) if margin: text = _re.sub('(?m)^' + margin, '', text) return text ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 23:52 Message: Logged In: YES user_id=80475 After more thought, I think the expandtabs() is a bug since it expands content tabs as well as margin tabs: >>> textwrap.dedent('\tABC\t\tDEF') 'ABC DEF' This is especially problematic given that dedent() has to guess at the tab size. If this gets fixed, I recommend using regular expressions as a way to indentify common margin prefixes on non-empty lines. This will also mixes of spaces and tabs without altering content with embedded tabs and without making assumptions about the tab size. Also, it ought to run somewhat faster. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 15:18 Message: Logged In: YES user_id=80475 FWIW, the tab expansion would be more useful if the default tabsize could be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 From noreply at sourceforge.net Thu Dec 15 06:56:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 21:56:21 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 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=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ken668 (ken668) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:56 Message: Logged In: YES user_id=33168 Do you still believe there is a problem or can this report be closed? ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 08:00 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Thu Dec 15 06:56:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 21:56:39 -0800 Subject: [ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs Message-ID: Bugs item #1377858, was opened at 2005-12-10 13:20 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Nobody/Anonymous (nobody) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 From noreply at sourceforge.net Thu Dec 15 06:58:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 21:58:23 -0800 Subject: [ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file Message-ID: Bugs item #1378755, was opened at 2005-12-12 06:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Didrik Pinte (dpinte) >Assigned to: Vinay Sajip (vsajip) Summary: logging : fileConfig does not check existance of the file Initial Comment: Hi, The fileConfig method from the logging.config module does not check for the existance of the config file before trying to load it. Worst, if the file does not exist, the exception is totally unrelated to the file. Example : did at geru-itea:~/$ python Python 2.3.5 (#2, Nov 20 2005, 16:40:39) [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import config >>> config.fileConfig('') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/logging/config.py", line 68, in fileConfig flist = cp.get("formatters", "keys") File "/usr/lib/python2.3/ConfigParser.py", line 505, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: 'formatters' It is really important that the exception is correctly reported. In fact, the problem seems to be here : /usr/lib/python2.3/ConfigParser.py, line 258 for filename in filenames: try: fp = open(filename) except IOError: continue self._read(fp, filename) The documentation of the read method says "Files that cannot be opened are silently ignored;". The behaviour of logging.config.fileConfig is highly related to the user actions. He must be informed of the fact that the logging system have not opened its file. I will provide a very basic path : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.file(fname)): raise IOError('Provided filename is not existing') ------------------------------------------------- Didrik ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:58 Message: Logged In: YES user_id=33168 Vinay, any comments? ---------------------------------------------------------------------- Comment By: Didrik Pinte (dpinte) Date: 2005-12-12 06:27 Message: Logged In: YES user_id=970259 Oups, the patch should be the following : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.isfile(fname)): raise IOError('Provided filename is not existing') ---------------------------------------------------------------------- Comment By: Didrik Pinte (dpinte) Date: 2005-12-12 06:25 Message: Logged In: YES user_id=970259 i've reported it for Python 2.4 but I reproduced it on Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 From noreply at sourceforge.net Thu Dec 15 07:00:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 22:00:11 -0800 Subject: [ python-Bugs-1378022 ] source utf8 Message-ID: Bugs item #1378022, was opened at 2005-12-10 22:48 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: zhao (ibear) Assigned to: Nobody/Anonymous (nobody) Summary: source utf8 Initial Comment: winxp sp2(chinese or japanese) and python 2.42 i have created a utf8 source file with BOM_UTF8 if i add a '#coding: utf8' at first line and run it, the python interpreter will crash ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-12 06:35 Message: Logged In: YES user_id=89016 The following patch (pythonrun.diff) should fix the segfault. However UTF-8 files with a leading BOM currently aren't supported. There's a pending patch (http://bugs.python.org/1177307) that adds a utf-8-sig codec for that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 From noreply at sourceforge.net Thu Dec 15 07:07:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 22:07:30 -0800 Subject: [ python-Bugs-1373161 ] r41552 broke test_file on OS X Message-ID: Bugs item #1373161, was opened at 2005-12-04 16:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: r41552 broke test_file on OS X Initial Comment: Apparently you *can* seek on sys.stdin here. If you just want seek() to fail sys.stdin.seek(-1) seems pretty likely to work... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 22:07 Message: Logged In: YES user_id=33168 Michael, I reverted the tell() portion. Do all the tests work for you now? Can this be closed? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-05 21:59 Message: Logged In: YES user_id=33168 Sorry, I think I closed the report before I saw that there was another problem. From a man page, it looked like tell() may fail if it is done on a pipe. So maybe the problem can't happen on OS X? We could check if the system is osx/darwin and skip the test. Do you want to skip the test? Since it was for coverage and to ensure nothing bad goes wrong with error handling, it's not awful that it can't be provoked on osx. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-05 01:31 Message: Logged In: YES user_id=6656 I suspect you know this from what I said on IRC, but test_file still fails, because you can tell() on sys.stdin too (I don't really see what you can do about this) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-04 17:17 Message: Logged In: YES user_id=33168 revision 41602 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 From noreply at sourceforge.net Thu Dec 15 07:44:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 22:44:41 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 17:03 Message generated for change (Comment added) made by ken668 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ken668 (ken668) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: ken668 (ken668) Date: 2005-12-14 22:44 Message: Logged In: YES user_id=1400763 Yes, it is a bug. My mistake was when I gave the details, I should have mentioned gc.get_objects(), not gc.garbage. gc.get_objects() showed the leaks not gc.garbage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:56 Message: Logged In: YES user_id=33168 Do you still believe there is a problem or can this report be closed? ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 08:00 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Thu Dec 15 09:18:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 00:18:53 -0800 Subject: [ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed Message-ID: Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Comment added) made by jjdmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- >Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 09:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 07:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 From noreply at sourceforge.net Thu Dec 15 09:32:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 00:32:19 -0800 Subject: [ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed Message-ID: Bugs item #1370380, was opened at 2005-11-30 13:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 00:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data)) That's it. And according to my reading of asynchat and asyncore, while actually trying to send data during a push() may trigger the handle_error() method to be called, by default, the handle_error() method logs the error and closes the socket. Errors don't seem to propagate out of push(). ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 00:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-13 22:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 From noreply at sourceforge.net Thu Dec 15 09:45:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 00:45:19 -0800 Subject: [ python-Bugs-1361643 ] textwrap.dedent() expands tabs Message-ID: Bugs item #1361643, was opened at 2005-11-19 20:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Steven Bethard (bediviere) Assigned to: Greg Ward (gward) Summary: textwrap.dedent() expands tabs Initial Comment: I'm not sure whether this is a documentation bug or a code bug, but textwrap.dedent() expands tabs (and AFAICT doesn't give the user any way of stopping this): py> def test(): ... x = ('abcd efgh\n' ... 'ijkl mnop\n') ... y = textwrap.dedent('''... abcd efgh ... ijkl mnop ... ''') ... return x, y ... py> test() ('abcd\tefgh\nijkl\tmnop\n', 'abcd efgh\nijkl mnop\n') Looking at the code, I can see the culprit is the first line: lines = text.expandtabs().split('\n') If this is the intended behavior, I think the first sentence in the documentation[1] should be replaced with: """ Replace all tabs in string with spaces as per str.expandtabs() and then remove any whitespace that can be uniformly removed from the left of every line in text. """ and (I guess this part is an RFE) textwrap.dedent() should gain an optional expandtabs= keyword argument to disable this behavior. If it's not the intended behavior, I'd love to see that .expandtabs() call removed. [1]http://docs.python.org/lib/module-textwrap.html ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 09:45 Message: Logged In: YES user_id=1188172 Looks good! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-20 07:04 Message: Logged In: YES user_id=80475 Suggested code: import re as _re _emptylines_with_spaces = _re.compile('(?m)^[ \t]+$') _prefixes_on_nonempty_lines = _re.compile('(?m)(^[ \t]*)(?:[^ \t\n]+)') def dedent(text): text = _emptylines_with_spaces.sub('', text) prefixes = _prefixes_on_nonempty_lines.findall(text) margin = min(prefixes or ['']) if margin: text = _re.sub('(?m)^' + margin, '', text) return text ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-20 05:52 Message: Logged In: YES user_id=80475 After more thought, I think the expandtabs() is a bug since it expands content tabs as well as margin tabs: >>> textwrap.dedent('\tABC\t\tDEF') 'ABC DEF' This is especially problematic given that dedent() has to guess at the tab size. If this gets fixed, I recommend using regular expressions as a way to indentify common margin prefixes on non-empty lines. This will also mixes of spaces and tabs without altering content with embedded tabs and without making assumptions about the tab size. Also, it ought to run somewhat faster. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 21:18 Message: Logged In: YES user_id=80475 FWIW, the tab expansion would be more useful if the default tabsize could be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 From noreply at sourceforge.net Thu Dec 15 10:00:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 01:00:33 -0800 Subject: [ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file Message-ID: Bugs item #1378755, was opened at 2005-12-12 14:24 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Didrik Pinte (dpinte) Assigned to: Vinay Sajip (vsajip) Summary: logging : fileConfig does not check existance of the file Initial Comment: Hi, The fileConfig method from the logging.config module does not check for the existance of the config file before trying to load it. Worst, if the file does not exist, the exception is totally unrelated to the file. Example : did at geru-itea:~/$ python Python 2.3.5 (#2, Nov 20 2005, 16:40:39) [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import config >>> config.fileConfig('') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/logging/config.py", line 68, in fileConfig flist = cp.get("formatters", "keys") File "/usr/lib/python2.3/ConfigParser.py", line 505, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: 'formatters' It is really important that the exception is correctly reported. In fact, the problem seems to be here : /usr/lib/python2.3/ConfigParser.py, line 258 for filename in filenames: try: fp = open(filename) except IOError: continue self._read(fp, filename) The documentation of the read method says "Files that cannot be opened are silently ignored;". The behaviour of logging.config.fileConfig is highly related to the user actions. He must be informed of the fact that the logging system have not opened its file. I will provide a very basic path : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.file(fname)): raise IOError('Provided filename is not existing') ------------------------------------------------- Didrik ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-12-15 09:00 Message: Logged In: YES user_id=308438 I don't believe this is a logging bug. The logging code defers to ConfigParser, and it is the responsibility of ConfigParser to raise exceptions with appropriate messages. Clearly, you could also pass an existing file with an invalid format - the logging config code does not try to do error recovery in these cases, but lets the exceptions propagate up to calling code. Doing otherwise would amount to defensive programming which I do not believe justified in this case. Please consider logging an issue against ConfigParser. After all, a change there would benefit more than just the logging package. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 05:58 Message: Logged In: YES user_id=33168 Vinay, any comments? ---------------------------------------------------------------------- Comment By: Didrik Pinte (dpinte) Date: 2005-12-12 14:27 Message: Logged In: YES user_id=970259 Oups, the patch should be the following : File /usr/lib/python2.3/logging/config.py, line 61 ------------------------------------------------- import os if not (os.path.isfile(fname)): raise IOError('Provided filename is not existing') ---------------------------------------------------------------------- Comment By: Didrik Pinte (dpinte) Date: 2005-12-12 14:25 Message: Logged In: YES user_id=970259 i've reported it for Python 2.4 but I reproduced it on Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470 From noreply at sourceforge.net Thu Dec 15 10:06:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 01:06:16 -0800 Subject: [ python-Bugs-1367814 ] loogger module locks Message-ID: Bugs item #1367814, was opened at 2005-11-27 23:31 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367814&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Chris Fuller (cfuller) Assigned to: Nobody/Anonymous (nobody) Summary: loogger module locks Initial Comment: I have an application that uses the logger functionality, and the RotatingFileHandler class. If my application is running, and another instance is launched, it fails at the rollover step. I don't want multiple instances running at once, so this is fine, and even general, since the rollover must occur if an instance is already running. Rather than checking for a generic I/O error, however, I'd like to use some sort of locking mechanism that is less opaque. The locking provided won't work, since it is blocking only: the application deadlocks if one ias runnning already. Why doesn't it work like a normal Lock() instance and take a blocking parameter? I could use locking via the portalocker module from the python cookbook (hmm, portable file locking would be a nice thing to have in the standard library, the logger module already does it anyway!) but I can't find anyway to access the file descriptor! Sure, I could workaround that. I could create a RotatingFileHandler instance, roll over, close it, open the file, pass it to StreamHandler, but python is way more elegant than that. For now, I'll just trap the rollover. Still very cool stuff! ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-12-15 09:06 Message: Logged In: YES user_id=308438 Closing, as this does not appear to be a bug report. Thanks for your comments. My advice (if you have multiple processes logging to the same file) is to add a separate logging process (or perhaps a thread in one of the processes) which receives logging events from a socket and logs to files. This way, there is no contention for the file. See http://docs.python.org/lib/network-logging.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367814&group_id=5470 From noreply at sourceforge.net Thu Dec 15 10:15:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 01:15:42 -0800 Subject: [ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed Message-ID: Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Comment added) made by jjdmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- >Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 10:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Could produce the following output: Connection lost Connection established with foo value 42 I wouldnt expect this from the documentation: push() adds data to the output buffer, but the docs dont say or imply it can fail and thus trigger handle_error (). A simple solution would be to put all push()es at the end of the function so that no more code is executed except maybe handle_error(). But as the example above shows, this is not always possible. Another solution would be one of your workarounds. If only the docs would be adapted, it would still bother me to have to do the above for any but the most trivial of applications. But once the docs warns me for this behaviour, I at least know it from the start :) So, do you feel docs/code should be changed, and if so, which one? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 09:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data)) That's it. And according to my reading of asynchat and asyncore, while actually trying to send data during a push() may trigger the handle_error() method to be called, by default, the handle_error() method logs the error and closes the socket. Errors don't seem to propagate out of push(). ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 09:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 07:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 From noreply at sourceforge.net Thu Dec 15 10:38:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 01:38:00 -0800 Subject: [ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed Message-ID: Bugs item #1370380, was opened at 2005-11-30 13:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 01:38 Message: Logged In: YES user_id=341410 If anything should be changed, I would say the docs. Though I disagree with the send during a call to push(), for most users, it makes sense, and convincing the current maintainer that removing the send on push for the sake of async purity would be difficulty (practicality beats purity). I believe that adding a note which reads something like the following would be sufficient. "The default push() implementation calls the underlying socket send() (to increase data throughput in many situations), and upon error, will call handle_error(). This may cause unexpected behavior if push() is used within a subclassed handle_connect()." ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 01:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Could produce the following output: Connection lost Connection established with foo value 42 I wouldnt expect this from the documentation: push() adds data to the output buffer, but the docs dont say or imply it can fail and thus trigger handle_error (). A simple solution would be to put all push()es at the end of the function so that no more code is executed except maybe handle_error(). But as the example above shows, this is not always possible. Another solution would be one of your workarounds. If only the docs would be adapted, it would still bother me to have to do the above for any but the most trivial of applications. But once the docs warns me for this behaviour, I at least know it from the start :) So, do you feel docs/code should be changed, and if so, which one? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 00:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data)) That's it. And according to my reading of asynchat and asyncore, while actually trying to send data during a push() may trigger the handle_error() method to be called, by default, the handle_error() method logs the error and closes the socket. Errors don't seem to propagate out of push(). ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 00:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-13 22:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 From noreply at sourceforge.net Thu Dec 15 11:14:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 02:14:49 -0800 Subject: [ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed Message-ID: Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Comment added) made by jjdmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- >Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 11:14 Message: Logged In: YES user_id=516066 Ok thanks. The example with handle_connect() is just one out of many btw: in general, don't run code after push() which uses or assumes data which handle_error() cleans up. There are indeed cases in which initiate_send() in a push() is practical. Aside from throughput issues, sending heartbeat messages or streaming data from another thread using a timer doesn't work without initiate_send, because the data wouldn't be sent until select() in the main thread feels like returning. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 10:38 Message: Logged In: YES user_id=341410 If anything should be changed, I would say the docs. Though I disagree with the send during a call to push(), for most users, it makes sense, and convincing the current maintainer that removing the send on push for the sake of async purity would be difficulty (practicality beats purity). I believe that adding a note which reads something like the following would be sufficient. "The default push() implementation calls the underlying socket send() (to increase data throughput in many situations), and upon error, will call handle_error(). This may cause unexpected behavior if push() is used within a subclassed handle_connect()." ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 10:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Could produce the following output: Connection lost Connection established with foo value 42 I wouldnt expect this from the documentation: push() adds data to the output buffer, but the docs dont say or imply it can fail and thus trigger handle_error (). A simple solution would be to put all push()es at the end of the function so that no more code is executed except maybe handle_error(). But as the example above shows, this is not always possible. Another solution would be one of your workarounds. If only the docs would be adapted, it would still bother me to have to do the above for any but the most trivial of applications. But once the docs warns me for this behaviour, I at least know it from the start :) So, do you feel docs/code should be changed, and if so, which one? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 09:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data)) That's it. And according to my reading of asynchat and asyncore, while actually trying to send data during a push() may trigger the handle_error() method to be called, by default, the handle_error() method logs the error and closes the socket. Errors don't seem to propagate out of push(). ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 09:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 07:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 From noreply at sourceforge.net Thu Dec 15 11:24:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 02:24:16 -0800 Subject: [ python-Bugs-212558 ] dictionary lookup does not check exceptions Message-ID: Bugs item #212558, was opened at 2000-08-23 14:24 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=212558&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 9 Submitted By: Jeremy Hylton (jhylton) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: dictionary lookup does not check exceptions Initial Comment: class BadDictKey: def __hash__(self): return hash(self.__class__) def __cmp__(self, other): if isinstance(other, self.__class__): print "raising error" raise RuntimeError, "gotcha" return other The dict lookup code does not check for hash or cmp functions raising an exception. This can lead to a variety of bogus behavior; e.g. the uncaught exception is noticed and raised for the next line. >>> d = {} >>> x1 = BadDictKey() >>> x2 = BadDictKey() >>> d[x1] = 1 >>> d[x2] = 2 raising error >>> print d.keys() Traceback (most recent call last): File "/tmp/dicterr.py", line 8, in __cmp__ raise RuntimeError, "gotcha" RuntimeError: gotcha ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-15 10:24 Message: Logged In: YES user_id=4771 For future reference, the patch number is actually #401277. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-08-31 19:05 Message: Fixed by patch #101277, checked in as dictobject.c revision 2.63. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-08-24 16:56 Message: See patch #101277 for a proposed fix & discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=212558&group_id=5470 From noreply at sourceforge.net Thu Dec 15 11:36:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 02:36:07 -0800 Subject: [ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed Message-ID: Bugs item #1370380, was opened at 2005-11-30 13:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 02:36 Message: Logged In: YES user_id=341410 Manipulating the same socket in two threads is a fool's business. If you want to force select to return, you should have a shorter timeout for select, or a loopback socket in which both ends are in the same process, where you can send some data, which causes the select to be triggered for a read event. ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 02:14 Message: Logged In: YES user_id=516066 Ok thanks. The example with handle_connect() is just one out of many btw: in general, don't run code after push() which uses or assumes data which handle_error() cleans up. There are indeed cases in which initiate_send() in a push() is practical. Aside from throughput issues, sending heartbeat messages or streaming data from another thread using a timer doesn't work without initiate_send, because the data wouldn't be sent until select() in the main thread feels like returning. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 01:38 Message: Logged In: YES user_id=341410 If anything should be changed, I would say the docs. Though I disagree with the send during a call to push(), for most users, it makes sense, and convincing the current maintainer that removing the send on push for the sake of async purity would be difficulty (practicality beats purity). I believe that adding a note which reads something like the following would be sufficient. "The default push() implementation calls the underlying socket send() (to increase data throughput in many situations), and upon error, will call handle_error(). This may cause unexpected behavior if push() is used within a subclassed handle_connect()." ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 01:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Could produce the following output: Connection lost Connection established with foo value 42 I wouldnt expect this from the documentation: push() adds data to the output buffer, but the docs dont say or imply it can fail and thus trigger handle_error (). A simple solution would be to put all push()es at the end of the function so that no more code is executed except maybe handle_error(). But as the example above shows, this is not always possible. Another solution would be one of your workarounds. If only the docs would be adapted, it would still bother me to have to do the above for any but the most trivial of applications. But once the docs warns me for this behaviour, I at least know it from the start :) So, do you feel docs/code should be changed, and if so, which one? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 00:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data)) That's it. And according to my reading of asynchat and asyncore, while actually trying to send data during a push() may trigger the handle_error() method to be called, by default, the handle_error() method logs the error and closes the socket. Errors don't seem to propagate out of push(). ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 00:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-13 22:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 From noreply at sourceforge.net Thu Dec 15 12:04:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 03:04:27 -0800 Subject: [ python-Bugs-1381476 ] csv.reader endless loop Message-ID: Bugs item #1381476, was opened at 2005-12-15 11:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christian Harms (wwwingman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.reader endless loop Initial Comment: Hi, the csv.reader produce a endless loop, ifan parsing Error is in the last line of the CSV-File. If you put an "\r" in the last line, cvs.Error is raised and StopIteration will lost. import csv, StringIO fp = StringIO.StringIO("line1\nline2\rerror") reader = csv.reader(fp) while 1: try: print reader.next() except csv.Error: print "Error" except StopIteration: break Die Problem is in python 2.3 AND python 2.4. Other version are not checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 From noreply at sourceforge.net Thu Dec 15 13:44:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 04:44:13 -0800 Subject: [ python-Bugs-1370380 ] async_chat.push() can trigger handle_error(). undocumented. Message-ID: Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Settings changed) made by jjdmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) >Summary: async_chat.push() can trigger handle_error(). undocumented. Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 11:36 Message: Logged In: YES user_id=341410 Manipulating the same socket in two threads is a fool's business. If you want to force select to return, you should have a shorter timeout for select, or a loopback socket in which both ends are in the same process, where you can send some data, which causes the select to be triggered for a read event. ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 11:14 Message: Logged In: YES user_id=516066 Ok thanks. The example with handle_connect() is just one out of many btw: in general, don't run code after push() which uses or assumes data which handle_error() cleans up. There are indeed cases in which initiate_send() in a push() is practical. Aside from throughput issues, sending heartbeat messages or streaming data from another thread using a timer doesn't work without initiate_send, because the data wouldn't be sent until select() in the main thread feels like returning. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 10:38 Message: Logged In: YES user_id=341410 If anything should be changed, I would say the docs. Though I disagree with the send during a call to push(), for most users, it makes sense, and convincing the current maintainer that removing the send on push for the sake of async purity would be difficulty (practicality beats purity). I believe that adding a note which reads something like the following would be sufficient. "The default push() implementation calls the underlying socket send() (to increase data throughput in many situations), and upon error, will call handle_error(). This may cause unexpected behavior if push() is used within a subclassed handle_connect()." ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 10:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Could produce the following output: Connection lost Connection established with foo value 42 I wouldnt expect this from the documentation: push() adds data to the output buffer, but the docs dont say or imply it can fail and thus trigger handle_error (). A simple solution would be to put all push()es at the end of the function so that no more code is executed except maybe handle_error(). But as the example above shows, this is not always possible. Another solution would be one of your workarounds. If only the docs would be adapted, it would still bother me to have to do the above for any but the most trivial of applications. But once the docs warns me for this behaviour, I at least know it from the start :) So, do you feel docs/code should be changed, and if so, which one? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 09:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data)) That's it. And according to my reading of asynchat and asyncore, while actually trying to send data during a push() may trigger the handle_error() method to be called, by default, the handle_error() method logs the error and closes the socket. Errors don't seem to propagate out of push(). ---------------------------------------------------------------------- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 09:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 07:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 From noreply at sourceforge.net Thu Dec 15 16:37:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 07:37:34 -0800 Subject: [ python-Bugs-1381717 ] mode 't' not documented as posssible mode for file built-in Message-ID: Bugs item #1381717, was opened at 2005-12-15 17: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=1381717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simo Salminen (ssalmine) Assigned to: Nobody/Anonymous (nobody) Summary: mode 't' not documented as posssible mode for file built-in Initial Comment: At http://docs.python.org/lib/built-in-funcs.html, 'file' function parameter 'mode' accepts 't' (for text mode). This is not documented. It is mentioned in file object description (http://docs.python.org/lib/bltin-file-objects.html). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470 From noreply at sourceforge.net Thu Dec 15 17:08:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 08:08:40 -0800 Subject: [ python-Bugs-1381717 ] mode 't' not documented as posssible mode for file built-in Message-ID: Bugs item #1381717, was opened at 2005-12-15 10:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simo Salminen (ssalmine) Assigned to: Nobody/Anonymous (nobody) Summary: mode 't' not documented as posssible mode for file built-in Initial Comment: At http://docs.python.org/lib/built-in-funcs.html, 'file' function parameter 'mode' accepts 't' (for text mode). This is not documented. It is mentioned in file object description (http://docs.python.org/lib/bltin-file-objects.html). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-12-15 11:08 Message: Logged In: YES user_id=31435 This is more involved than you might like. In general, open(path, mode) passes the mode string to the platform C library's file-opening function, and using anything other than standard C mode letters ("w", "b", "r", "a", "+") is platform-dependent. "t" is not a standard C mode letter, so whether it has any meaning, and exactly what it means if it _does_ mean something, depends entirely on the platform C library. Using "t" to force text mode is a Microsoft-specific gimmick, so if "t" is documented at all, it should be plastered with warnings about its platform-specific nature. Even on a Microsoft platform, "t" is basically silly: text mode is the default mode (C defines this) -- it's what you get if you don't pass "b". The only reason Microsoft supports "t" is because MS has _another_ non-standard option to tell its C runtime to use binary mode by default, and if you use that non-standard option then you also need to use the non-standard "t" mode letter to force a file to open in text mode. In short, the docs should change to spell out what the standard C modes are, and note that at the cost of portability you can also pass whichever non-standard mode extensions your platform happens to support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470 From noreply at sourceforge.net Thu Dec 15 22:15:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 13:15:41 -0800 Subject: [ python-Bugs-1381939 ] cElementTree only supports a few encodings Message-ID: Bugs item #1381939, was opened at 2005-12-15 22: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=1381939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: cElementTree only supports a few encodings Initial Comment: The cElementTree driver only supports a small number of XML encodings compared to ElementTree (and other pyexpat-based tools). This would be nice if this was fixed before 2.5 final. In the meantime, a workaround can be found here: http://effbot.org/zone/celementtree-encoding.htm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&group_id=5470 From noreply at sourceforge.net Thu Dec 15 22:36:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 13:36:17 -0800 Subject: [ python-Bugs-1381717 ] mode 't' not documented as posssible mode for file built-in Message-ID: Bugs item #1381717, was opened at 2005-12-15 16:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simo Salminen (ssalmine) Assigned to: Nobody/Anonymous (nobody) Summary: mode 't' not documented as posssible mode for file built-in Initial Comment: At http://docs.python.org/lib/built-in-funcs.html, 'file' function parameter 'mode' accepts 't' (for text mode). This is not documented. It is mentioned in file object description (http://docs.python.org/lib/bltin-file-objects.html). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:36 Message: Logged In: YES user_id=1188172 I removed the reference to "t" from the docs of file.seek() in rev 41703,41704. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-12-15 17:08 Message: Logged In: YES user_id=31435 This is more involved than you might like. In general, open(path, mode) passes the mode string to the platform C library's file-opening function, and using anything other than standard C mode letters ("w", "b", "r", "a", "+") is platform-dependent. "t" is not a standard C mode letter, so whether it has any meaning, and exactly what it means if it _does_ mean something, depends entirely on the platform C library. Using "t" to force text mode is a Microsoft-specific gimmick, so if "t" is documented at all, it should be plastered with warnings about its platform-specific nature. Even on a Microsoft platform, "t" is basically silly: text mode is the default mode (C defines this) -- it's what you get if you don't pass "b". The only reason Microsoft supports "t" is because MS has _another_ non-standard option to tell its C runtime to use binary mode by default, and if you use that non-standard option then you also need to use the non-standard "t" mode letter to force a file to open in text mode. In short, the docs should change to spell out what the standard C modes are, and note that at the cost of portability you can also pass whichever non-standard mode extensions your platform happens to support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470 From noreply at sourceforge.net Thu Dec 15 22:39:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 13:39:27 -0800 Subject: [ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken Message-ID: Bugs item #1379994, was opened at 2005-12-14 01:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Mc Mahon (markmcmahon) Assigned to: M.-A. Lemburg (lemburg) Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken Initial Comment: In Python 2.4.2 and Python 2.4.1 (Windows XP) >>> "\t\t".encode("string_escape") '\t\\t' >>> "\t\t".encode("unicode_escape") '\t\t' >>> "\t\t".encode("raw_unicode_escape") '\t\t' >>> u"\t\t".encode("unicode_escape") '\t\t' >>> u"\t\t".encode("raw_unicode_escape") '\t\t' I would have expected all to produce the same result. Also round-tripping with the encoding doesn't seem to work: >>> "\t\t".encode('string_escape').decode('string_escape') '\t\t' >>> u"\t\t".encode('unicode_escape').decode('unicode_escape') u'\t\t' Thanks Mark ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:39 Message: Logged In: YES user_id=1188172 Patch looks good. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-14 02:41 Message: Logged In: YES user_id=55188 Attached a patch. It looks like a simple typo. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 From noreply at sourceforge.net Thu Dec 15 22:40:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 13:40:17 -0800 Subject: [ python-Feature Requests-1379573 ] python executable optionally should search script on PATH Message-ID: Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 From noreply at sourceforge.net Thu Dec 15 22:42:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 13:42:50 -0800 Subject: [ python-Bugs-1379393 ] StreamReader.readline doesn't advance on decode errors Message-ID: Bugs item #1379393, was opened at 2005-12-13 11:35 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Walter D?rwald (doerwalter) Summary: StreamReader.readline doesn't advance on decode errors Initial Comment: In previous versions of python, when there was a unicode decode error, StreamReader.readline() would advance to the next line. In the current version(2.4.2 and trunk), it doesn't. Testing under Linux AMD64 (Ubuntu 5.10) Attaching an example script. In python2.3 it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 2: unexpected code byte error: 'utf8' codec can't decode byte 0x81 in position 2: unexpected code byte all done In python2.4 and trunk it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte [repeats forever] Maybe this isn't actually supposed to work (the docs don't mention what should happen with strict error checking..), but it would be nice, given the alternatives: 1. use errors='replace' and then search the result for the replacement character. (ick) 2. define a custom error handler similar to ignore or replace, that also sets some flag. (slightly less ick, but more work.) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:42 Message: Logged In: YES user_id=1188172 I don't know what should be correct. Walter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470 From noreply at sourceforge.net Thu Dec 15 22:59:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 13:59:57 -0800 Subject: [ python-Bugs-1378455 ] a problem of urllib using open_local_file Message-ID: Bugs item #1378455, was opened at 2005-12-12 03:10 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Weongyo Jeong (weongyo) Assigned to: Nobody/Anonymous (nobody) Summary: a problem of urllib using open_local_file Initial Comment: Hello. I'm sorry for my short english. I'm using python 2.4 on my windows system. But I have a problem. see below: -------------------->3----------------->3------- Traceback (most recent call last): File "main.py", line 57, in uploadproc UNNAMED_toplev.main (self.liststore.get_value (iter, i)) File "C:\Work\unnamed\UNNAMED_toplev.py", line 59, in main toplev_main (doc, TARGET_FILE) File "C:\Work\unnamed\UNNAMED_toplev.py", line 51, in toplev_main doc.documentElement.appendChild (UNNAMED_filehash.GetSHA1Info (doc, filepath )) File "C:\Work\unnamed\UNNAMED_filehash.py", line 19, in GetSHA1Info file = urllib.urlopen (filepath) File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 185, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 421, in open_file return self.open_local_file(url) File "C:\Python24\lib\urllib.py", line 435, in open_local_file raise IOError(e.errno, e.strerror, e.filename) IOError: [Errno 2] No such file or directory: '\C:\pse_signature.psr' -------------------->3----------------->3------- i made a simple GUI program with pygtk and do drag and drop a file from windows file explorer. It printed "file:///C:/pse_signature.psr" which is a type of "text/uri-list". But urllib can't process it. Is it a problem of urllib? I read a article which reported a same problem with my case in python 2.2. that "file:///C:/pse_signature.psr" string made by windows. not me. why this problem don't be fixed? are there any reasons? thanks for reading. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:59 Message: Logged In: YES user_id=1188172 Fixed in r41705,41706. Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&group_id=5470 From noreply at sourceforge.net Thu Dec 15 23:00:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 14:00:17 -0800 Subject: [ python-Feature Requests-1379573 ] python executable optionally should search script on PATH Message-ID: Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by cconrad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. ---------------------------------------------------------------------- >Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 From noreply at sourceforge.net Thu Dec 15 23:00:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 14:00:34 -0800 Subject: [ python-Bugs-1378455 ] a problem of urllib using open_local_file Message-ID: Bugs item #1378455, was opened at 2005-12-12 03:10 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Weongyo Jeong (weongyo) Assigned to: Nobody/Anonymous (nobody) Summary: a problem of urllib using open_local_file Initial Comment: Hello. I'm sorry for my short english. I'm using python 2.4 on my windows system. But I have a problem. see below: -------------------->3----------------->3------- Traceback (most recent call last): File "main.py", line 57, in uploadproc UNNAMED_toplev.main (self.liststore.get_value (iter, i)) File "C:\Work\unnamed\UNNAMED_toplev.py", line 59, in main toplev_main (doc, TARGET_FILE) File "C:\Work\unnamed\UNNAMED_toplev.py", line 51, in toplev_main doc.documentElement.appendChild (UNNAMED_filehash.GetSHA1Info (doc, filepath )) File "C:\Work\unnamed\UNNAMED_filehash.py", line 19, in GetSHA1Info file = urllib.urlopen (filepath) File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 185, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 421, in open_file return self.open_local_file(url) File "C:\Python24\lib\urllib.py", line 435, in open_local_file raise IOError(e.errno, e.strerror, e.filename) IOError: [Errno 2] No such file or directory: '\C:\pse_signature.psr' -------------------->3----------------->3------- i made a simple GUI program with pygtk and do drag and drop a file from windows file explorer. It printed "file:///C:/pse_signature.psr" which is a type of "text/uri-list". But urllib can't process it. Is it a problem of urllib? I read a article which reported a same problem with my case in python 2.2. that "file:///C:/pse_signature.psr" string made by windows. not me. why this problem don't be fixed? are there any reasons? thanks for reading. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=1188172 I should add that the problem was not in urllib itself, but nturl2path. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:59 Message: Logged In: YES user_id=1188172 Fixed in r41705,41706. Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&group_id=5470 From noreply at sourceforge.net Thu Dec 15 23:10:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 14:10:50 -0800 Subject: [ python-Bugs-1163401 ] uncaught AttributeError deep in urllib Message-ID: Bugs item #1163401, was opened at 2005-03-15 01:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: K Lars Lohn (lohnk) Assigned to: Nobody/Anonymous (nobody) Summary: uncaught AttributeError deep in urllib Initial Comment: Python 2.4 and Python 2.3.4 running under Suse 9.2 We're getting an AttributeError exception "AttributeError: 'NoneType' object has no attribute 'read'" within a very simple call to urllib.urlopen. This was discovered while working on Sentry 2, the new mirror integrity checker for the Mozilla project. We try to touch hundreds of URLs to make sure that the files are present on each of the mirrors. One particular URL kills the call to urllib.urlopen: http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe This file probably does not exist on the mirror, however, in other cases of bad URLs, we get much more graceful failures when we try to read from the object returned by urllib.urlopen. >>> import urllib >>> urlReader = urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen return opener.open(url) File "/usr/local/lib/python2.4/urllib.py", line 180, in open return getattr(self, name)(url) File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__ addbase.__init__(self, fp) File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' The attached file is a three line scipt that demos the problem. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 23:10 Message: Logged In: YES user_id=1188172 Duplicate of #767111. ---------------------------------------------------------------------- Comment By: Roy Smith (roysmith) Date: 2005-04-02 23:44 Message: Logged In: YES user_id=390499 Wow, this is bizarre. I just spend some time tracking down exactly this same bug and was just about to enter it when I saw this entry. For what it's worth, I can reliably reproduce this exception when fetching a URL from a deliberately broken server (well, at least I think it's broken; have to double-check the HTTP spec to be sure this isn't actually allowed) which produces headers but no body: (This is on Mac OSX-10.3.8, Python-2.3.4) ------------------------------- Roy-Smiths-Computer:bug$ cat server.py #!/usr/bin/env python from BaseHTTPServer import * class NullHandler (BaseHTTPRequestHandler): def do_GET (self): self.send_response (100) self.end_headers () server = HTTPServer (('', 8000), NullHandler) server.handle_request() ------------------------------ Roy-Smiths-Computer:bug$ cat client.py #!/usr/bin/env python import urllib urllib.urlopen ('http://127.0.0.1:8000') --------------------------------- Roy-Smiths-Computer:bug$ ./client.py Traceback (most recent call last): File "./client.py", line 5, in ? urllib.urlopen ('http://127.0.0.1:8000') File "/usr/local/lib/python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/usr/local/lib/python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/usr/local/lib/python2.3/urllib.py", line 306, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/usr/local/lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/usr/local/lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/usr/local/lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/usr/local/lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' --------------------------------- I'll give urllib2 a try and see how that works. ---------------------------------------------------------------------- Comment By: K Lars Lohn (lohnk) Date: 2005-03-16 18:07 Message: Logged In: YES user_id=1239273 I've changed over to urllib2. The only complication involved the exception handling model: urllib2's HTTPError exceptions cannot be pickled because they contain an open socket._fileobject. While mildly inconvenient, the workaround was not difficult. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-03-15 20:09 Message: Logged In: YES user_id=44345 Looking through the code I believe I traced the problem back to httplib.HTTP which sets self.fp to None when it's closed. It seems that urllib is trying to access this object after the connection's been closed. I realize the problem has passed for the moment, but have you considered using urllib2? The urllib library still uses httplib.HTTP which is really only there for backward compatibility. From this end it would be nice to leave urllib and httplib.HTTP alone. New apps should probably use urllib2 which uses the newer httplib.HTTPConnection class. ---------------------------------------------------------------------- Comment By: K Lars Lohn (lohnk) Date: 2005-03-15 17:50 Message: Logged In: YES user_id=1239273 This problem is apparently transient depending on network conditions or, perhaps, the configuration of the server end. On 3/14 the problem has mysteriously vanished.... ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2005-03-15 10:52 Message: Logged In: YES user_id=92222 No such error on Windows: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470 From noreply at sourceforge.net Thu Dec 15 23:11:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 14:11:23 -0800 Subject: [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 14:52 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 23:11 Message: Logged In: YES user_id=1188172 Further information can be found in #1163401 which has been closed as a duplicate. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-01-07 13:39 Message: Logged In: YES user_id=11375 No, not at this point in time. Unassigning (or, if this bug is on the radar for 2.3.5/2.4.1, I can find time to work on it). - ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-01-07 13:39 Message: Logged In: YES user_id=11375 No, not at this point in time. Unassigning (or, if this bug is on the radar for 2.3.5/2.4.1, I can find time to work on it). - ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-07 02:37 Message: Logged In: YES user_id=80475 Andrew, are you still working on this one? ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-19 00:43 Message: Logged In: YES user_id=1000470 The file pointer (fp) is None (inside urllib) from httplib. This appears to be caused by a BadStatusLine exception in getreply() (line1016 httplib). This sets self.file to self._conn.sock.makefile('rb', 0) then does a self.close() which sets self.file to None. Being new to this peice of code, I'm not sure whether it's urllib assuming the file isn't going to be closed, or the BadStatusLine exception clearing the file. Certainly it looks like the error -1 is not being trapped by open_http() in urllib upon calling h.getreply() and assuming that the file still exists even in an error condition? It maybe a coincidence but it appears to occur more when a web browser on the same machine is refreshing. Regards Rob ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-17 23:24 Message: Logged In: YES user_id=1000470 """ This comment is program to reproduce the problem. Sorry it's not an attachment - as a relative Sourceforge newbie I have no idea how to attach to an existing bug. More notes available via email if required - including all local variables for each function from post mortem. As said before, seems to be fp = None. Although the exception is caused by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside open_http() This is repeatable, but you may have to run this more than once. (Apologies to noaa.gov). *** PLEASE: Run only where absolutely necessary for reproduction of bug!!! *** """ """ Attribute Error test case - Python 2.3 """ import urllib url = "http://adds.aviationweather.noaa.gov/metars/index.php" params = urllib.urlencode({ "station_ids" : "KJFK", "hoursStr" : "most recent only", "std_trans" : "standard", "chk_metars" : "on", "submit":"Submit"}) print "test" for i in range(1, 1000): x = urllib.urlopen(url, params) string = x.read() print i """ Local variables for middle level routine... classURLopener open_http(self, url, data=None) args ('User-agent', 'Python-urllib/1.15') auth None data 'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub mit=Submit&chk_metars=on' errcode -1 errmsg '' fp None h headers None host 'adds.aviationweather.noaa.gov' httplib realhost 'adds.aviationweather.noaa.gov' selector '/metars/index.php' self url '//adds.aviationweather.noaa.gov/metars/index.php' user_passwd None """ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 05:23 Message: Logged In: YES user_id=12800 Please provide a self-contained, complete example that we can use to reproduce this problem. Without enough information, I can't see us fixing this for Python 2.3, and time for that is rapidly running out. Lowering to priority 6. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-17 06:34 Message: Logged In: YES user_id=46639 I've finally managed to get another traceback with some more information, using an assert I inserted into urllib.py a while ago to catch .fp == None: Traceback (most recent call last): File "/Users/zen/bin/autospamrep.py", line 168, in ? current_page = urllib.urlopen(start_url).read() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 305, in open_http assert fp is not None, 'errcode %r, errmsg %r, headers %r' % (errcode, errmsg, headers) AssertionError: errcode -1, errmsg '', headers None ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 15:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 07:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply at sourceforge.net Fri Dec 16 00:07:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 15:07:30 -0800 Subject: [ python-Bugs-1381939 ] cElementTree only supports a few encodings Message-ID: Bugs item #1381939, was opened at 2005-12-15 22:15 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: cElementTree only supports a few encodings Initial Comment: The cElementTree driver only supports a small number of XML encodings compared to ElementTree (and other pyexpat-based tools). This would be nice if this was fixed before 2.5 final. In the meantime, a workaround can be found here: http://effbot.org/zone/celementtree-encoding.htm ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-16 00:07 Message: Logged In: YES user_id=38376 I've attached the relevant patch from CET 1.0.5 (in progress) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&group_id=5470 From noreply at sourceforge.net Fri Dec 16 03:22:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 18:22:35 -0800 Subject: [ python-Bugs-1382096 ] MacRoman Encoding Bug (OHM vs. OMEGA) Message-ID: Bugs item #1382096, was opened at 2005-12-16 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=105470&aid=1382096&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean B. Palmer (seanbpalmer) Assigned to: M.-A. Lemburg (lemburg) Summary: MacRoman Encoding Bug (OHM vs. OMEGA) Initial Comment: The file encodings/mac_roman.py in Python 2.4.1 contains the following incorrect character definition on line 96: 0x00bd: 0x2126, # OHM SIGN This should read: 0x00bd: 0x03A9, # GREEK CAPITAL LETTER OMEGA Presumably this bug occurred due to a misreading, given that OHM and OMEGA having the same glyph. Evidence that the OMEGA interpretation is correct: 0xBD 0x03A9 # GREEK CAPITAL LETTER OMEGA -http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT Further evidence can be found by Googling for MacRoman tables. This bug means that, for example, the following code gives a UnicodeEncodeError when it shouldn't do: >>> u'\u03a9'.encode('macroman') For a workaround, I've been using the following code: >>> import codecs >>> from encodings import mac_roman >>> mac_roman.decoding_map[0xBD] = 0x03A9 >>> mac_roman.encoding_map = codecs.make_encoding_map(mac_roman.decoding_map) And then, to use the example above: >>> u'\u03a9'.encode('macroman') '\xbd' >>> Thanks, -- Sean B. Palmer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382096&group_id=5470 From noreply at sourceforge.net Fri Dec 16 08:08:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 23:08:32 -0800 Subject: [ python-Bugs-1382213 ] Tutorial section 9.5.1 ignores MRO for new-style classes Message-ID: Bugs item #1382213, was opened at 2005-12-16 18: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=1382213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: GaryD (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial section 9.5.1 ignores MRO for new-style classes Initial Comment: Section 9.5.1 ("Multiple Inheritance") of the tutorial (as viewed on http://www.python.org/doc/2.4.2/tut/) discusses the Method Resolution Order (MRO) for classes with multiple inheritance. However, the 2nd paragraph incorrectly states that "The only rule necessary to explain the semantics is the resolution rule used for class attribute references. This is depth-first, left-to-right". Whilst this is true for old-style classes, new-style classes use a different MRO (as documented elsewhere - eg. http://www.python.org/2.3/mro.html) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382213&group_id=5470 From noreply at sourceforge.net Fri Dec 16 08:17:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 23:17:48 -0800 Subject: [ python-Bugs-1382213 ] Tutorial section 9.5.1 ignores MRO for new-style classes Message-ID: Bugs item #1382213, was opened at 2005-12-16 02:08 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: GaryD (gazzadee) >Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial section 9.5.1 ignores MRO for new-style classes Initial Comment: Section 9.5.1 ("Multiple Inheritance") of the tutorial (as viewed on http://www.python.org/doc/2.4.2/tut/) discusses the Method Resolution Order (MRO) for classes with multiple inheritance. However, the 2nd paragraph incorrectly states that "The only rule necessary to explain the semantics is the resolution rule used for class attribute references. This is depth-first, left-to-right". Whilst this is true for old-style classes, new-style classes use a different MRO (as documented elsewhere - eg. http://www.python.org/2.3/mro.html) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382213&group_id=5470 From noreply at sourceforge.net Fri Dec 16 15:47:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 06:47:10 -0800 Subject: [ python-Bugs-1382096 ] MacRoman Encoding Bug (OHM vs. OMEGA) Message-ID: Bugs item #1382096, was opened at 2005-12-16 03:22 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382096&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sean B. Palmer (seanbpalmer) Assigned to: M.-A. Lemburg (lemburg) Summary: MacRoman Encoding Bug (OHM vs. OMEGA) Initial Comment: The file encodings/mac_roman.py in Python 2.4.1 contains the following incorrect character definition on line 96: 0x00bd: 0x2126, # OHM SIGN This should read: 0x00bd: 0x03A9, # GREEK CAPITAL LETTER OMEGA Presumably this bug occurred due to a misreading, given that OHM and OMEGA having the same glyph. Evidence that the OMEGA interpretation is correct: 0xBD 0x03A9 # GREEK CAPITAL LETTER OMEGA -http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT Further evidence can be found by Googling for MacRoman tables. This bug means that, for example, the following code gives a UnicodeEncodeError when it shouldn't do: >>> u'\u03a9'.encode('macroman') For a workaround, I've been using the following code: >>> import codecs >>> from encodings import mac_roman >>> mac_roman.decoding_map[0xBD] = 0x03A9 >>> mac_roman.encoding_map = codecs.make_encoding_map(mac_roman.decoding_map) And then, to use the example above: >>> u'\u03a9'.encode('macroman') '\xbd' >>> Thanks, -- Sean B. Palmer ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-16 15:47 Message: Logged In: YES user_id=38388 This has been fixed in CVS and Python 2.5 will include the fix. A backport is not possible, because we've changed the way charmap codecs work in 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382096&group_id=5470 From noreply at sourceforge.net Fri Dec 16 16:01:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 07:01:14 -0800 Subject: [ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken Message-ID: Bugs item #1379994, was opened at 2005-12-14 01:47 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Mc Mahon (markmcmahon) >Assigned to: Hye-Shik Chang (perky) Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken Initial Comment: In Python 2.4.2 and Python 2.4.1 (Windows XP) >>> "\t\t".encode("string_escape") '\t\\t' >>> "\t\t".encode("unicode_escape") '\t\t' >>> "\t\t".encode("raw_unicode_escape") '\t\t' >>> u"\t\t".encode("unicode_escape") '\t\t' >>> u"\t\t".encode("raw_unicode_escape") '\t\t' I would have expected all to produce the same result. Also round-tripping with the encoding doesn't seem to work: >>> "\t\t".encode('string_escape').decode('string_escape') '\t\t' >>> u"\t\t".encode('unicode_escape').decode('unicode_escape') u'\t\t' Thanks Mark ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-16 16:01 Message: Logged In: YES user_id=38388 Please add a test case and check in the patch. Thanks. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:39 Message: Logged In: YES user_id=1188172 Patch looks good. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-14 02:41 Message: Logged In: YES user_id=55188 Attached a patch. It looks like a simple typo. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 From noreply at sourceforge.net Fri Dec 16 17:59:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 08:59:54 -0800 Subject: [ python-Bugs-1382562 ] --install-base not honored on win32 Message-ID: Bugs item #1382562, was opened at 2005-12-16 16: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=1382562&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: --install-base not honored on win32 Initial Comment: The --install-base options isn't honored on win32 because code in install.finalize_others() in install.py overwrites the value with either self.home, self.prefix, or sys.prefix. I was trying to use --install-base because --prefix won't accept an absolute path on win32. Does anyone know the rationale for rejecting absolute paths on win32? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382562&group_id=5470 From noreply at sourceforge.net Fri Dec 16 18:25:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 09:25:49 -0800 Subject: [ python-Bugs-1379393 ] StreamReader.readline doesn't advance on decode errors Message-ID: Bugs item #1379393, was opened at 2005-12-13 11:35 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Walter D?rwald (doerwalter) Summary: StreamReader.readline doesn't advance on decode errors Initial Comment: In previous versions of python, when there was a unicode decode error, StreamReader.readline() would advance to the next line. In the current version(2.4.2 and trunk), it doesn't. Testing under Linux AMD64 (Ubuntu 5.10) Attaching an example script. In python2.3 it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 2: unexpected code byte error: 'utf8' codec can't decode byte 0x81 in position 2: unexpected code byte all done In python2.4 and trunk it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte [repeats forever] Maybe this isn't actually supposed to work (the docs don't mention what should happen with strict error checking..), but it would be nice, given the alternatives: 1. use errors='replace' and then search the result for the replacement character. (ick) 2. define a custom error handler similar to ignore or replace, that also sets some flag. (slightly less ick, but more work.) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-12-16 18:25 Message: Logged In: YES user_id=89016 IMHO the current behaviour is more consistent. To read the broken utf-8 stream from the test script the appropriate error handler should be used. What is the desired outcome? If only the broken byte sequence should be skipped errors="replace" is appropriate. To skip a complete line that contains a broken byte sequence do something like in the attached skipbadlines.py. The StreamReader can't know which behaviour is wanted. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:42 Message: Logged In: YES user_id=1188172 I don't know what should be correct. Walter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470 From noreply at sourceforge.net Fri Dec 16 18:27:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 09:27:43 -0800 Subject: [ python-Feature Requests-1370948 ] Start and end parameters for list.count() Message-ID: Feature Requests item #1370948, was opened at 2005-12-01 10:12 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1370948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Start and end parameters for list.count() Initial Comment: For lists and strings, the index() method has start and end parameters. For strings, the count() method has start and end parameters as well. But for lists, the count() method has no such parameters. I think it may be a good idea to allow start and end parameters for count() on lists as well, if only for consistency reasons. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-16 12:27 Message: Logged In: YES user_id=80475 See discussion for patch 1382087. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1370948&group_id=5470 From noreply at sourceforge.net Fri Dec 16 20:43:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:43:39 -0800 Subject: [ python-Bugs-1283289 ] PyArg_ParseTupleAndKeywords gives misleading error message Message-ID: Bugs item #1283289, was opened at 2005-09-06 21:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: japierro (japierro) >Assigned to: Martin v. L?wis (loewis) Summary: PyArg_ParseTupleAndKeywords gives misleading error message Initial Comment: Python 2.3.3 on Windows XP If the user supplies one valid and one invalid keyword to a function that defines two required keyword arguments, PyArg_ParseTupleAndKeywords will raise this exception: TypeError: function takes exactly 2 arguments (1 given) If, in getargs.c, vgetargskeywords, the check for "extraneous keywords" were done near the top of the function, a more meaningful exception would be thrown: TypeError: 'bad' is an invalid keyword argument for this function ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 20:43 Message: Logged In: YES user_id=1188172 Any opinions? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283289&group_id=5470 From noreply at sourceforge.net Fri Dec 16 21:18:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 12:18:24 -0800 Subject: [ python-Bugs-1382740 ] len() on class broken Message-ID: Bugs item #1382740, was opened at 2005-12-16 13:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 From noreply at sourceforge.net Fri Dec 16 22:38:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 13:38:38 -0800 Subject: [ python-Bugs-1382815 ] len() on class broken Message-ID: Bugs item #1382815, was opened at 2005-12-16 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=1382815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382815&group_id=5470 From noreply at sourceforge.net Fri Dec 16 22:40:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 13:40:43 -0800 Subject: [ python-Bugs-1382815 ] len() on class broken Message-ID: Bugs item #1382815, was opened at 2005-12-16 22:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 22:40 Message: Logged In: YES user_id=1188172 Duplicate of #1382740. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382815&group_id=5470 From noreply at sourceforge.net Fri Dec 16 22:43:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 13:43:52 -0800 Subject: [ python-Bugs-1382740 ] len() on class broken Message-ID: Bugs item #1382740, was opened at 2005-12-16 21:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 22:43 Message: Logged In: YES user_id=1188172 You want to use a metaclass: class meta(type): def __len__(cls): return 12 class B: __metaclass__ = B print len(B) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 From noreply at sourceforge.net Fri Dec 16 22:47:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 13:47:36 -0800 Subject: [ python-Bugs-1382562 ] --install-base not honored on win32 Message-ID: Bugs item #1382562, was opened at 2005-12-16 17:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382562&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) >Assigned to: Martin v. L?wis (loewis) Summary: --install-base not honored on win32 Initial Comment: The --install-base options isn't honored on win32 because code in install.finalize_others() in install.py overwrites the value with either self.home, self.prefix, or sys.prefix. I was trying to use --install-base because --prefix won't accept an absolute path on win32. Does anyone know the rationale for rejecting absolute paths on win32? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 22:47 Message: Logged In: YES user_id=1188172 Martin, I think you are the Windows-install-guru... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382562&group_id=5470 From noreply at sourceforge.net Fri Dec 16 22:49:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 13:49:34 -0800 Subject: [ python-Bugs-1355883 ] make depend/clean issues w/ ast Message-ID: Bugs item #1355883, was opened at 2005-11-13 14:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: make depend/clean issues w/ ast Initial Comment: I noticed two issues with the ast vis a vis building and cleaning. Haven't had a chance to look into them, however... 1. From a fresh checkout, execute configure, then "make -j2". It will run Parser/asdl_c.py twice simultaneously. This can obviously lead to corrupt Python-ast.[ch] files. 2. Neither "make clean" nor "make distclean" delete the Python-ast.[ch] files. "make distclean" at least should. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 22:49 Message: Logged In: YES user_id=1188172 Is that still an issue? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:58 Message: Logged In: YES user_id=315535 Fix for part 1 here: http://sourceforge.net/tracker/index.php?func=detail&aid=1355971&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:45 Message: Logged In: YES user_id=315535 Already on it :) Shall have a patch up shortly. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-13 17:44 Message: Logged In: YES user_id=44345 I was thinking it might be something like that. Perhaps asdl_c.py should be modified to accept an output flag (--output=[hc] or -h/-c) so it only generates one file or the other. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:24 Message: Logged In: YES user_id=315535 The first problem is being caused by a simple misunderstanding/oversight in Makefile.pre.in. The rule for a target will be called for each target. In our case, we have Python-ast.h and Python-ast.c in our list of targets. So asdl_c.py gets called once for each target. Hope this makes sense. :) If not I can bang up a patch so you can at least see what I'm on about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 From noreply at sourceforge.net Fri Dec 16 23:09:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 14:09:05 -0800 Subject: [ python-Bugs-1381939 ] cElementTree only supports a few encodings Message-ID: Bugs item #1381939, was opened at 2005-12-15 22:15 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: cElementTree only supports a few encodings Initial Comment: The cElementTree driver only supports a small number of XML encodings compared to ElementTree (and other pyexpat-based tools). This would be nice if this was fixed before 2.5 final. In the meantime, a workaround can be found here: http://effbot.org/zone/celementtree-encoding.htm ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-16 23:09 Message: Logged In: YES user_id=38376 Fixed in revision 41724 ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-16 00:07 Message: Logged In: YES user_id=38376 I've attached the relevant patch from CET 1.0.5 (in progress) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&group_id=5470 From noreply at sourceforge.net Fri Dec 16 23:52:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 14:52:25 -0800 Subject: [ python-Bugs-1382740 ] len() on class broken Message-ID: Bugs item #1382740, was opened at 2005-12-16 13:18 Message generated for change (Settings changed) made by kquick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. ---------------------------------------------------------------------- >Comment By: Kevin Quick (kquick) Date: 2005-12-16 15:52 Message: Logged In: YES user_id=6133 That would indeed solve '4', but has a non-orthogonality of attribute propagation that I don't understand and which seems inconsistent. In my original: '1' demonstrates that __len__ is indeed in the dictionary for the class. '2' shows the expected attribute propagation effects: if at attribute is not found in the instance dictionary, the class dictionary is checked. '3' shows that len is implemented (generally) by looking for a __len__ method on the object in question. '4' confuses me, because it means that '3' isn't quite correct... With your metaclass solution (using "__metaclass__ = meta" :) it does indeed make '4' work, and '1', but '2' and '3' now do not work, showing that instance-->class propagation does not follow instance-->class-->metaclass. Or something ... Approaching this a different way: My understanding of @classmethod (or perhaps more properly @staticmethod) is that it allows "constant" methods that are independent of the particular object instance. So if I had: class C: @staticmethod def f(): return 1 then both C.f() and C().f() are valid and return 1. Why the len() translation to __len__ works *differently* is strange. I'm still defining a method, just one that I want Python to use for any len(A) or len(A()) refs, translating those to A.__len__() or A().__len__() and using those just as for C and f, respectively. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 14:43 Message: Logged In: YES user_id=1188172 You want to use a metaclass: class meta(type): def __len__(cls): return 12 class B: __metaclass__ = B print len(B) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 From noreply at sourceforge.net Sat Dec 17 05:39:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 20:39:26 -0800 Subject: [ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken Message-ID: Bugs item #1379994, was opened at 2005-12-14 09:47 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Mc Mahon (markmcmahon) Assigned to: Hye-Shik Chang (perky) Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken Initial Comment: In Python 2.4.2 and Python 2.4.1 (Windows XP) >>> "\t\\t".encode("string_escape") '\\t\\\\t' >>> "\t\\t".encode("unicode_escape") '\\t\\t' >>> "\t\\t".encode("raw_unicode_escape") '\t\\t' >>> u"\t\\t".encode("unicode_escape") '\\t\\t' >>> u"\t\\t".encode("raw_unicode_escape") '\t\\t' I would have expected all to produce the same result. Also round-tripping with the encoding doesn't seem to work: >>> "\t\\t".encode('string_escape').decode('string_escape') '\t\\t' >>> u"\t\\t".encode('unicode_escape').decode('unicode_escape') u'\t\t' Thanks Mark ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-17 13:39 Message: Logged In: YES user_id=55188 Committed as r41728. Thank you! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-17 00:01 Message: Logged In: YES user_id=38388 Please add a test case and check in the patch. Thanks. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 06:39 Message: Logged In: YES user_id=1188172 Patch looks good. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-14 10:41 Message: Logged In: YES user_id=55188 Attached a patch. It looks like a simple typo. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470 From noreply at sourceforge.net Sat Dec 17 05:40:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 20:40:47 -0800 Subject: [ python-Bugs-1382740 ] len() on class broken Message-ID: Bugs item #1382740, was opened at 2005-12-16 15:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open >Resolution: None Priority: 5 Submitted By: Kevin Quick (kquick) >Assigned to: Guido van Rossum (gvanrossum) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-16 23:40 Message: Logged In: YES user_id=80475 Guido, this issue arises throughout the language in various guises (for instance, it applies to __neg__ as well as __len__). It comes-up whenever built-in functions or operators bypass attribute lookup in favor of direct slot access. Much of the code in abstract.c is in the form: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) raise TypeError If we cared about this (and I'm not sure we do), the solution is to make the abstract.c functions smarter: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) try: f = gettattr(o, 'somefunc') except AttributeError: raise TypeError else: return f() The advantage of the change is restoring the symmetry between len(o) and o.__len__() where the method definition is available via attribute lookup but not via a slot. The thought is to keep the speedy access as default, but if that fails, then do a normal attribute lookup before barfing back an error message. This is precedent for this solution elsewhere in the codebase (though I don't remember where at the moment). OTOH, I'm not sure we care. pervades the code in abstract.c which is in the form: def PyObject_Size ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2005-12-16 17:52 Message: Logged In: YES user_id=6133 That would indeed solve '4', but has a non-orthogonality of attribute propagation that I don't understand and which seems inconsistent. In my original: '1' demonstrates that __len__ is indeed in the dictionary for the class. '2' shows the expected attribute propagation effects: if at attribute is not found in the instance dictionary, the class dictionary is checked. '3' shows that len is implemented (generally) by looking for a __len__ method on the object in question. '4' confuses me, because it means that '3' isn't quite correct... With your metaclass solution (using "__metaclass__ = meta" :) it does indeed make '4' work, and '1', but '2' and '3' now do not work, showing that instance-->class propagation does not follow instance-->class-->metaclass. Or something ... Approaching this a different way: My understanding of @classmethod (or perhaps more properly @staticmethod) is that it allows "constant" methods that are independent of the particular object instance. So if I had: class C: @staticmethod def f(): return 1 then both C.f() and C().f() are valid and return 1. Why the len() translation to __len__ works *differently* is strange. I'm still defining a method, just one that I want Python to use for any len(A) or len(A()) refs, translating those to A.__len__() or A().__len__() and using those just as for C and f, respectively. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 16:43 Message: Logged In: YES user_id=1188172 You want to use a metaclass: class meta(type): def __len__(cls): return 12 class B: __metaclass__ = B print len(B) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 From noreply at sourceforge.net Sat Dec 17 16:17:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 07:17:30 -0800 Subject: [ python-Bugs-1381476 ] csv.reader endless loop Message-ID: Bugs item #1381476, was opened at 2005-12-15 21:04 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christian Harms (wwwingman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.reader endless loop Initial Comment: Hi, the csv.reader produce a endless loop, ifan parsing Error is in the last line of the CSV-File. If you put an "\r" in the last line, cvs.Error is raised and StopIteration will lost. import csv, StringIO fp = StringIO.StringIO("line1\nline2\rerror") reader = csv.reader(fp) while 1: try: print reader.next() except csv.Error: print "Error" except StopIteration: break Die Problem is in python 2.3 AND python 2.4. Other version are not checked. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-12-18 01:17 Message: Logged In: YES user_id=315535 I think this may be fixed in subversion: tom at vanilla:~/work/python$ svn info Path: . URL: http://svn.python.org/projects/python/trunk Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 41731 Node Kind: directory Schedule: normal Last Changed Author: fredrik.lundh Last Changed Rev: 41729 Last Changed Date: 2005-12-17 18:33:21 +1000 (Sat, 17 Dec 2005) Properties Last Updated: 2005-12-17 21:44:46 +1000 (Sat, 17 Dec 2005) tom at vanilla:~/work/python$ python -V Python 2.4.2 tom at vanilla:~/work/python$ python Sandbox/csv_reader_test.py ['line1'] ERROR: newline inside string tom at vanilla:~/work/python$ ./python -V Python 2.5a0 tom at vanilla:~/work/python$ ./python Sandbox/csv_reader_test.py ['line1'] ERROR: new-line character seen in unquoted field - do you need to open the file in universal-newline mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 From noreply at sourceforge.net Sat Dec 17 17:12:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 08:12:19 -0800 Subject: [ python-Bugs-1383644 ] MacOS.WMAvailable() doesn't launch Python.app properly Message-ID: Bugs item #1383644, was opened at 2005-12-17 16:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1383644&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: MacOS.WMAvailable() doesn't launch Python.app properly Initial Comment: Running the following on Apple-installed Python 2.3.5 on OS 10.4.3: ~ has$ pythonw Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MacOS >>> MacOS.WMAvailable() True a Python.app process starts to launch as expected; however its icon remains bouncing indefinitely in the Dock. Additional prodding, e.g.: >>> import Carbon.Evt >>> Carbon.Evt.WaitNextEvent(0,0) (0, (0, 0, 1141622, (751, 225), 128)) causes it to finish launching as expected (Dock icon stops bouncing, small black triangle appears next to it). Third-party has confirmed this problem. Might be a problem with WMAvailable(), might be a problem in Python.app. Don't know enough Carbon to determine this myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1383644&group_id=5470 From noreply at sourceforge.net Sat Dec 17 17:56:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 08:56:13 -0800 Subject: [ python-Bugs-1381476 ] csv.reader endless loop Message-ID: Bugs item #1381476, was opened at 2005-12-15 21:04 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christian Harms (wwwingman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.reader endless loop Initial Comment: Hi, the csv.reader produce a endless loop, ifan parsing Error is in the last line of the CSV-File. If you put an "\r" in the last line, cvs.Error is raised and StopIteration will lost. import csv, StringIO fp = StringIO.StringIO("line1\nline2\rerror") reader = csv.reader(fp) while 1: try: print reader.next() except csv.Error: print "Error" except StopIteration: break Die Problem is in python 2.3 AND python 2.4. Other version are not checked. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-12-18 02:56 Message: Logged In: YES user_id=315535 Actually, the problem may not be a problem with the csv module at all, it may be a misinterpretation of the API on the submitters part. Is there any time a non-fatal csv.Error would/could be raised? Seems to me that a csv.Error would imply a StopIteration/break ... ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-12-18 01:17 Message: Logged In: YES user_id=315535 I think this may be fixed in subversion: tom at vanilla:~/work/python$ svn info Path: . URL: http://svn.python.org/projects/python/trunk Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 41731 Node Kind: directory Schedule: normal Last Changed Author: fredrik.lundh Last Changed Rev: 41729 Last Changed Date: 2005-12-17 18:33:21 +1000 (Sat, 17 Dec 2005) Properties Last Updated: 2005-12-17 21:44:46 +1000 (Sat, 17 Dec 2005) tom at vanilla:~/work/python$ python -V Python 2.4.2 tom at vanilla:~/work/python$ python Sandbox/csv_reader_test.py ['line1'] ERROR: newline inside string tom at vanilla:~/work/python$ ./python -V Python 2.5a0 tom at vanilla:~/work/python$ ./python Sandbox/csv_reader_test.py ['line1'] ERROR: new-line character seen in unquoted field - do you need to open the file in universal-newline mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 From noreply at sourceforge.net Sat Dec 17 18:02:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 09:02:25 -0800 Subject: [ python-Bugs-1381476 ] csv.reader endless loop Message-ID: Bugs item #1381476, was opened at 2005-12-15 12:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christian Harms (wwwingman) >Assigned to: Andrew McNamara (andrewmcnamara) Summary: csv.reader endless loop Initial Comment: Hi, the csv.reader produce a endless loop, ifan parsing Error is in the last line of the CSV-File. If you put an "\r" in the last line, cvs.Error is raised and StopIteration will lost. import csv, StringIO fp = StringIO.StringIO("line1\nline2\rerror") reader = csv.reader(fp) while 1: try: print reader.next() except csv.Error: print "Error" except StopIteration: break Die Problem is in python 2.3 AND python 2.4. Other version are not checked. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 18:02 Message: Logged In: YES user_id=1188172 Let the expert judge. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-12-17 17:56 Message: Logged In: YES user_id=315535 Actually, the problem may not be a problem with the csv module at all, it may be a misinterpretation of the API on the submitters part. Is there any time a non-fatal csv.Error would/could be raised? Seems to me that a csv.Error would imply a StopIteration/break ... ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-12-17 16:17 Message: Logged In: YES user_id=315535 I think this may be fixed in subversion: tom at vanilla:~/work/python$ svn info Path: . URL: http://svn.python.org/projects/python/trunk Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 41731 Node Kind: directory Schedule: normal Last Changed Author: fredrik.lundh Last Changed Rev: 41729 Last Changed Date: 2005-12-17 18:33:21 +1000 (Sat, 17 Dec 2005) Properties Last Updated: 2005-12-17 21:44:46 +1000 (Sat, 17 Dec 2005) tom at vanilla:~/work/python$ python -V Python 2.4.2 tom at vanilla:~/work/python$ python Sandbox/csv_reader_test.py ['line1'] ERROR: newline inside string tom at vanilla:~/work/python$ ./python -V Python 2.5a0 tom at vanilla:~/work/python$ ./python Sandbox/csv_reader_test.py ['line1'] ERROR: new-line character seen in unquoted field - do you need to open the file in universal-newline mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 From noreply at sourceforge.net Sat Dec 17 18:15:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 09:15:05 -0800 Subject: [ python-Bugs-1106572 ] os.makedirs() ignores mode parameter Message-ID: Bugs item #1106572, was opened at 2005-01-21 10:42 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs() ignores mode parameter Initial Comment: os.makedirs('foo/x', 0777) does not create the directories with permissions g+rwx,u+rwx,o+rwx but instead: >>> import os >>> os.makedirs('foo/xx', 0777) >>> [2]+ Stopped python2.3 ajung at hrs2dev2:~/sandboxes/haufecms/instance/Products/HaufeCMS: ls -la foo insgesamt 12 drwxr-xr-x 3 ajung ajung 4096 2005-01-21 10:39 . drwxr-xr-x 19 ajung ajung 4096 2005-01-21 10:39 .. drwxr-xr-x 2 ajung ajung 4096 2005-01-21 10:39 xx This happens with Python 2.3.4 on Linux ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 18:15 Message: Logged In: YES user_id=1188172 Clarified the docs in rev. 41732/41733. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2005-01-26 14:22 Message: Logged In: YES user_id=11084 umask(0) does the job. In this case the documentation is completely misleading. The API reads as the 'mode' parameter is *the* umask. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:48 Message: Logged In: YES user_id=9205 What is the current process umask? The resulting directory mode will always be (mode & ~umask & 0777). To be sure that os.makedirs() will use the given mode without modification, you have to execute os.umask(0) beforehand. So this bug is probably invalid if you forgot to set your umask accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470 From noreply at sourceforge.net Sat Dec 17 18:31:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 09:31:40 -0800 Subject: [ python-Bugs-1343671 ] Broken docs for os.removedirs Message-ID: Bugs item #1343671, was opened at 2005-10-31 12:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: David K?gedal (d_kagedal) Assigned to: Nobody/Anonymous (nobody) Summary: Broken docs for os.removedirs Initial Comment: The documentation for the os.removedirs function is seriously broken. This is from the library reference: "removedirs(path) Removes directories recursively. Works like rmdir() except that, if the leaf directory is successfully removed, directories corresponding to rightmost path segments will be pruned way until either the whole path is consumed or an error is raised (which is ignored, because it generally means that a parent directory is not empty). Throws an error exception if the leaf directory could not be successfully removed. New in version 1.5.2." The first sentence is the only part that makes any sense. This shorter version contains as much information and less misinformation" "removedirs(path) Removes a directory and everything in it recursively. If a file couldn't be removed, the removal is aborted and you might get an exception if you're lucky." The doc string you get when you type "help(os.removedirs)" is different from the one in the library reference, but equally broken. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 18:31 Message: Logged In: YES user_id=1188172 Fixed the docs in rev. 41734/41735. ---------------------------------------------------------------------- Comment By: David K?gedal (d_kagedal) Date: 2005-11-13 22:11 Message: Logged In: YES user_id=1260741 > Are you sure you understand how the function works? No I'm not. But that's the whole point of this bug report. Reading the documentation didn't help. Saying "Removes directories recursively" means something different to me than what you describe, so I think it's easy to mislead already there. When it sans that "rightmost path segments will be pruned away", that doesn't tell me that anything will be removed from the file system, does it? My suggestion for new doc string wasn't meant to be accepted, but more to describe what information the original contained. How about this then: Removes the given directory, just like rmdir(). In addition, if the removal was successful, the parent directories mentioned in the 'path' argument are removed if they are now empty. This is done by removing the last path segment from the given path and trying to remove the directory given by the remaining path, until there is nothing left of the original path string. No exception will be raised while trying to remove parent directories. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:54 Message: Logged In: YES user_id=38376 (I've changed the docstring from "remove a leaf directory and empty all intermediate ones" to "remove a leaf directory and all empty intermediate ones". both the docstring and the docs could need some clarification, but the text you propose is not really an improvement...) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:49 Message: Logged In: YES user_id=38376 Are you sure you understand how the function works? Given "spam/egg/bacon", it first attempts to do an rmdir on spam/egg/bacon. If that fails, the function raises an exception. Otherwise, it proceeds to rmdir spam/egg and spam. Errors during the latter stage are ignored. If you want to remove directories whether they're empty or not, use shutil.rmtree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 From noreply at sourceforge.net Sat Dec 17 18:49:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 09:49:55 -0800 Subject: [ python-Bugs-1373197 ] os.makedirs fail if path contains os.pardir Message-ID: Bugs item #1373197, was opened at 2005-12-05 03:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs fail if path contains os.pardir Initial Comment: os.makedirs fail with "OSError: [Errno 17] File exists:" error when trying to create paths like 'a/b/../c' or 'a/b/c/..'. Seen on 2.3.0, 2.4.1 and 2.5.0. Included patch with new test cases that fail with current 2.5 code. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 18:49 Message: Logged In: YES user_id=1188172 It's not clear what os.makedirs should do with such arguments. It should stay simple and not try to correct bad paths. I amended the docs to spell that out in rev. 41736/41737. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-05 03:08 Message: Logged In: YES user_id=832344 And here are the tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373197&group_id=5470 From noreply at sourceforge.net Sun Dec 18 02:18:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 17:18:11 -0800 Subject: [ python-Bugs-1384175 ] random module - Provider DLL failed to initialize correctly Message-ID: Bugs item #1384175, was opened at 2005-12-18 01:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: random module - Provider DLL failed to initialize correctly Initial Comment: File "random.pyc", line 828, in ? File "random.pyc", line 95, in __init__ File "random.pyc", line 109, in seed WindowsError: [Errno -2146893795] Provider DLL failed to initialize correctly ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470 From noreply at sourceforge.net Sun Dec 18 06:29:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 21:29:56 -0800 Subject: [ python-Bugs-1378022 ] source utf8 Message-ID: Bugs item #1378022, was opened at 2005-12-10 22:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Parser/Compiler >Group: Python 2.4 >Status: Closed >Resolution: Fixed >Priority: 5 Submitted By: zhao (ibear) >Assigned to: Neal Norwitz (nnorwitz) Summary: source utf8 Initial Comment: winxp sp2(chinese or japanese) and python 2.42 i have created a utf8 source file with BOM_UTF8 if i add a '#coding: utf8' at first line and run it, the python interpreter will crash ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 21:29 Message: Logged In: YES user_id=33168 Thank you for the bug report. Committed revision 41753. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-12 06:35 Message: Logged In: YES user_id=89016 The following patch (pythonrun.diff) should fix the segfault. However UTF-8 files with a leading BOM currently aren't supported. There's a pending patch (http://bugs.python.org/1177307) that adds a utf-8-sig codec for that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 From noreply at sourceforge.net Sun Dec 18 07:03:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 22:03:47 -0800 Subject: [ python-Bugs-1378022 ] source utf8 Message-ID: Bugs item #1378022, was opened at 2005-12-10 22:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: zhao (ibear) Assigned to: Neal Norwitz (nnorwitz) Summary: source utf8 Initial Comment: winxp sp2(chinese or japanese) and python 2.42 i have created a utf8 source file with BOM_UTF8 if i add a '#coding: utf8' at first line and run it, the python interpreter will crash ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 22:03 Message: Logged In: YES user_id=33168 Thank you for the bug report. Committed revision 41753. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 21:29 Message: Logged In: YES user_id=33168 Thank you for the bug report. Committed revision 41753. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-12 06:35 Message: Logged In: YES user_id=89016 The following patch (pythonrun.diff) should fix the segfault. However UTF-8 files with a leading BOM currently aren't supported. There's a pending patch (http://bugs.python.org/1177307) that adds a utf-8-sig codec for that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 From noreply at sourceforge.net Sun Dec 18 08:10:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 23:10:26 -0800 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 03:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 23:10 Message: Logged In: YES user_id=33168 EXTENDED_ARG problem was fixed a while ago. The assert/pass problem was fixed with: 41756. That leaves the LOAD_CONST/POP_TOP optimization that was lost and one compiler warning: marshal_write_mod() not being used. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 16:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 15:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 02:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 12:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-22 21:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 00:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 04:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Sun Dec 18 11:57:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 02:57:19 -0800 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 22:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-18 11:57 Message: Logged In: YES user_id=1188172 This was addressed with patch #1144555, which has been applied to the 2.5 branch only (as it is a new feature). Closing as "Out of Date". ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 20:37 Message: Logged In: YES user_id=341410 You could just pass fp.fstat(fp.fileno()).st_size to all of your instances, not just the unix ones. Right now, Python exposes the underlying mmap implementation. Windows automatically handles the statting/etc., for using the full size of the file in an mmap. Other platforms don't. While it would seem reasonable to have the unix specific implementation automatically perform an os.fstat(), actually calling the requisite code in os from mmapmodule.c is a pain in the ass (in my experience), and duplicating the code in mmapmodule.c is a poor idea. I would suggest you offer a documentation patch in the patch tracker to state the behavior of Unix mmap and suggested cross-platform workarounds. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-11-08 20:15 Message: Logged In: YES user_id=197677 The bug report is still right here in this listing. What are the possible solutions? 1) Not have the Windows version map the entire file length. Could break existing code, so not likely. 2) Have the UNIX version map the entire file when a length of 0 is passed. Since the fp is passed, the code can get length from os.fstat(fp.fileno()).st_size. There could be some code handling this exception whose operation would change if this modification were made. 3) Modify the documentation to be more explicit about valid and invalid length values on the UNIX version. Providing and example using fp.fstat(fp.fileno()).st_size would be very helpful. I see the third option as the only viable path at this point. Letting the Windows path use zero as a magic indicator is an impediment to writing cross-platform code. An example in the documentation of how it could be done is sorely needed. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 19:11 Message: Logged In: YES user_id=341410 According to the documentation, in Windows, passing a 'length' of 0 will map the entire file. On 'Unix', it does not discuss what happens when you use a length of 0. The behavior on undefined arguments in the case of linux could almost be expected (though perhaps should be clarified in documentation), and being that the 'cygwin' platform isn't Windows (it's a unix-like environment in Windows), expecting it to perform like Windows, is probably Wasn't your bug report that you could not map 0 bytes from the file, or that passing '0' did not do what you expected on Linux and/or cygwin? If so, then maybe the documentation should be updated. To respond to "wouldn't os.stat(filename).st_size be good to pass during mmap creation time?" Of course, I do that myself, and I would expect most sane people to do the same. os.fstat(fp.fileno()).st_size also works. So, what is your bug report again, and why is this bug report open? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-11-08 16:16 Message: Logged In: YES user_id=197677 If the file was created by another process or specified as a parameter, the code might not be free to write into it. Asking os.stat() for the file size works on both platforms. I have not tested on any other platform, but I do not see any reason it would not work. fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) Even if the file were just created, surely asking os.stat() for the file size would not have more overhead than writing to the file. Does it? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 07:17 Message: Logged In: YES user_id=341410 On Windows and Linux, I have been able to map positive, nonzero portions of files for quite some time. The only use-case I can see in using an mmap of size 0 is if the file was just created, and a user wanted to immediately resize the mmap to be larger. This can be worked-around with a simple fp.write('\0'), followed by a mmap call with size 1. Resize as desired/necessary. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-10-28 23:09 Message: Logged In: YES user_id=197677 It would be helpful to creating cross-platform code for all platforms to have the same requirements. If this is marked as Not-A-Bug, then how about changing it to a documentation bug so that and example could be provided? fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Sun Dec 18 12:00:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 03:00:26 -0800 Subject: [ python-Bugs-1384175 ] random module - Provider DLL failed to initialize correctly Message-ID: Bugs item #1384175, was opened at 2005-12-18 02:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: random module - Provider DLL failed to initialize correctly Initial Comment: File "random.pyc", line 828, in ? File "random.pyc", line 95, in __init__ File "random.pyc", line 109, in seed WindowsError: [Errno -2146893795] Provider DLL failed to initialize correctly ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-18 12:00 Message: Logged In: YES user_id=1188172 Could you provide some more information? OS specs, Python version, reproducability etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470 From noreply at sourceforge.net Mon Dec 19 04:30:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 19:30:59 -0800 Subject: [ python-Bugs-783990 ] test_re failure on 64bit targets (alpha, ia64) Message-ID: Bugs item #783990, was opened at 2003-08-06 00:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783990&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Neal Norwitz (nnorwitz) Summary: test_re failure on 64bit targets (alpha, ia64) Initial Comment: test test_re failed -- Traceback (most recent call last): File "/home/doko/py/python2.3-2.3/Lib/test/test_re.py", line 283, in test_bigcharset u"\u2222").group(1), u"\u2222") AttributeError: 'NoneType' object has no attribute 'group' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 19:30 Message: Logged In: YES user_id=33168 Assuming this is fixed based on comments and lack of response. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 22:52 Message: Logged In: YES user_id=33168 Hmmm, from the last comment it seems like this problem has been fixed. Unless I hear otherwise, I will close soon. ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-09-03 16:22 Message: Logged In: YES user_id=555 This test 'test_re' doesn't fail for last night's snapshot, on Linux/ia64 or Linux/amd64. It also doesn't fail for python2.3 on Tru64. So probably this could be closed as 'fixed'. (Note, though, that the test 'test_bigcharset' doesn't really test re.UNICODE very well.) ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-08-06 00:18 Message: Logged In: YES user_id=60903 this should be alpha-linux, ia64-linux, didn't test any other OS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783990&group_id=5470 From noreply at sourceforge.net Mon Dec 19 04:36:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 19:36:25 -0800 Subject: [ python-Bugs-808596 ] apparently leaking snippet Message-ID: Bugs item #808596, was opened at 2003-09-18 07:48 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: apparently leaking snippet Initial Comment: Raymond Hettinger found that the following: fd, fname = tempfile.mkstemp() execfile(fname) leaks a reference. TrackRefs sez it's a string. Haven't dug any further. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 19:36 Message: Logged In: YES user_id=33168 I just tested this on 2.5a and there were no ref leaks, so closing again. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 06:46 Message: Logged In: YES user_id=6656 Reopening, as it turned out interning filenames did do some good. Lowering priority as it isn't a real leak. It's still kinda annoying, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-03 03:25 Message: Logged In: YES user_id=6656 Done, in Python/compile.c revision 2.312. test_pkgimport turned out to be something else (sys.path_importer_cache), so I feel no need to try and be clever with dummy's refcounting today. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 08:11 Message: Logged In: YES user_id=80475 Not interning the filename seems cleanest. Like you, I do not expect that interning provided any real benefit here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 05:56 Message: Logged In: YES user_id=6656 I've finally worked out what's going on here. It's because compiling the file interns the name of the file being compiled. Now that interned strings are mortal, this isn't a big deal, but it still results in a string being added to and removed from the interned strings dictionary with net result (almost all of the time) of incrementing the refcount on 'dummy' by one. Once in every thousand or so iterations this results in the interned string dictionary being resized and throwing all the references to dummy away, so this isn't a 'real' leak. OTOH, I'd still like to do something about this (as is, test_pkg appears to leak 10 references per run because of this). The simplest thing would be to just plain not intern the filename during compilation (I find it hard to believe that it's of any real benefit). The more invasive solution would be to not do refcounting on dummy (assuming that's even possible) which is a scarier change, but would stop similar problems with other tests (I have a feeling that test_pkgimport appears to be leaking references because of a different incarnation of the same problem). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 From noreply at sourceforge.net Mon Dec 19 04:39:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 19:39:06 -0800 Subject: [ python-Bugs-816810 ] webbrowser.open hangs under certain conditions Message-ID: Bugs item #816810, was opened at 2003-10-02 14:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816810&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.open hangs under certain conditions Initial Comment: On Unix, if you have galeon installed and no BROWSER environment variable, webbrowser.open('http://...') will hang if there is no galeon running at the time of the call. The problem is, webbrowser.open calls "galeon <the URL>". If a galeon instance is running, the new invocation will signal the old about the URL and then exit. If there is no galeon instance running, the new instance will do the job itself and not exit, so the call to webbrowser.open() will hang until you exit galeon. Skip had this to say: In the meantime, it looks like if you modify the definition of cmd in Galeon._remote to cmd = "%s %s %s & >/dev/null 2>&1" % (self.name, raise_opt, action) that webbrowser.open() should return for you. I'm not sure the '&' is sufficient though. You may lose the Galeon instance if you then exit from the Python interpreter. In general, the code in webbrowser._remote() looks a bit hackish. I'm not sure I like this: rc = os.system(cmd) if rc: import time os.system("%s >/dev/null 2>&1 &" % self.name) time.sleep(PROCESS_CREATION_DELAY) rc = os.system(cmd) Oh well, it's what we're stuck with... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 19:39 Message: Logged In: YES user_id=33168 webbrowser was pretty much re-written, so I'm assuming this is at least out of date, and hopefully fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816810&group_id=5470 From noreply at sourceforge.net Mon Dec 19 04:41:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 19:41:12 -0800 Subject: [ python-Bugs-830573 ] python 2.3.2 make test segfault Message-ID: Bugs item #830573, was opened at 2003-10-26 09:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Karel Kulhav? (clock_) Assigned to: Neal Norwitz (nnorwitz) Summary: python 2.3.2 make test segfault Initial Comment: When compiling python 2.3.2 on my platform, running make test produces segfault of python executable. typescript included. gcc 3.2.2 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 19:41 Message: Logged In: YES user_id=33168 Closing due to lack of information. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 23:38 Message: Logged In: YES user_id=33168 Karel, can you provide any more information about this problem? If not, we will have to close since it's not reproducible. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-27 06:11 Message: Logged In: YES user_id=21627 Can you provide more detail about your platform (e.g. OS name, OS vendor, version of BerkeleyDB installed). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-27 06:06 Message: Logged In: YES user_id=33168 The test that crashes is anydbm. I wonder if this could be related to the bsddb problems? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830573&group_id=5470 From noreply at sourceforge.net Mon Dec 19 04:45:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 19:45:12 -0800 Subject: [ python-Bugs-856623 ] Erroneous code objects created with PyCode_New Message-ID: Bugs item #856623, was opened at 2003-12-08 19:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Tim McLennan (timmcl) Assigned to: Neal Norwitz (nnorwitz) Summary: Erroneous code objects created with PyCode_New Initial Comment: If you copy a code object by calling say new.code with just the members of an existing code object with free/cell variables - such as the following nested example: def null(): return None def wrapfunc(func): def _inner(*args): return func(*args) return _inner wrapped = wrapfunc(null) code_object = wrapped.func_code new_code_object = new.code(< code_object >) then the new_code_object will not have had its free/cell vars removed and will thus not disassemble correctly. Furthermore if you create a function out of it, then calling the function will raise - SystemError: R:Python23srcPython-2.3.2Objectscellobject.c: 22: bad argument to internal function Looking at the code in PyCode_New I can't see why this should happen. (Bug noticed on Python 2.3.2 on windows) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 19:45 Message: Logged In: YES user_id=33168 Assuming this is fixed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 23:59 Message: Logged In: YES user_id=33168 I don't think this is still a bug any longer. new.function() seems to require closure be passed in if the function has cell variables. When I disassemble new_code_object, I get the same as the original. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856623&group_id=5470 From noreply at sourceforge.net Mon Dec 19 04:49:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 19:49:18 -0800 Subject: [ python-Bugs-881812 ] 2.4a0 build fails in Modules/signalmodule.c Message-ID: Bugs item #881812, was opened at 2004-01-21 15:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=881812&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: David Dyck (dcd) >Assigned to: Neal Norwitz (nnorwitz) Summary: 2.4a0 build fails in Modules/signalmodule.c Initial Comment: PYTHON_VERSION, 2.4a0 (Jan 21 CVS) gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/signalmodule.c -o Modules/signalmodule.o ./Modules/signalmodule.c: In function `signal_handler': ./Modules/signalmodule.c:141: warning: implicit declaration of function `siginterrupt' ./Modules/signalmodule.c: In function `initsignal': ./Modules/signalmodule.c:550: `_NSIG' undeclared (first use in this function) ./Modules/signalmodule.c:550: (Each undeclared identifier is reported only once ./Modules/signalmodule.c:550: for each function it appears in.) make: *** [Modules/signalmodule.o] Error 1 (At one time my libc5 linux system had similar troubles building perl, but perl's Configure get's it right the hard way) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 19:49 Message: Logged In: YES user_id=33168 I don't think we will be able to support libc5. If someone can come up with a patch, we can add it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-10-18 19:53 Message: Logged In: YES user_id=33168 That's odd. Line 544 is using SIGRTMAX. I presume SIGRTMAX is defined as _NSIG on your system? I don't know why it would do that. Can you try to produce a patch? What type of platform is this (beyond libc5 based)? ---------------------------------------------------------------------- Comment By: David Dyck (dcd) Date: 2004-10-18 08:56 Message: Logged In: YES user_id=53855 The line numbers have changed but the error remains in Python-2.4b1 gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/signalmodule.c -o Modules/signalmodule.o ./Modules/signalmodule.c: In function `initsignal': ./Modules/signalmodule.c:544: `_NSIG' undeclared (first use in this function) ./Modules/signalmodule.c:544: (Each undeclared identifier is reported only once ./Modules/signalmodule.c:544: for each function it appears in.) make: *** [Modules/signalmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-10-17 13:54 Message: Logged In: YES user_id=33168 Is this still a problem w/ 2.4b1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=881812&group_id=5470 From noreply at sourceforge.net Mon Dec 19 05:28:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 20:28:05 -0800 Subject: [ python-Bugs-889500 ] Line 0 SyntaxWarning with duplicate global declarations Message-ID: Bugs item #889500, was opened at 2004-02-02 20:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889500&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) >Assigned to: Neal Norwitz (nnorwitz) Summary: Line 0 SyntaxWarning with duplicate global declarations Initial Comment: global a a = "b" global a a.py:0: SyntaxWarning: name 'a' is assigned to before global declaration This is a fairly minor bug, however, the message is misleading (the variable is in fact assigned to both before and after the global declaration). At least, the line number should be fixed to refer to the second declaration, and if possible the error message should be changed to "duplicate global declaration of 'a'". P.S.: If "global a" is repeated multiple times, the error message will be repeated, with the same line number, and no indication that the warning refers to a different line. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 20:28 Message: Logged In: YES user_id=33168 Fixed for 2.5. Thanks for the bug report. Committed revision 41767. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-02-13 14:47 Message: Logged In: YES user_id=593130 >if possible the error message should be changed to "duplicate global declaration of 'a'". The ref man does not prohibit duplicate declarations, nor is duplication essential to get the misleading line number: >>> def f(): ... global a ... b = 0 ... global b ... :1: SyntaxWarning: name 'b' is assigned to before global declaration It appears that compiler treats additional global declarations as continuations of first and only stores one line #, the first, for the 'combined' declaration. If code is too difficult to change, perhaps ref man could make note of this ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889500&group_id=5470 From noreply at sourceforge.net Mon Dec 19 05:40:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 20:40:11 -0800 Subject: [ python-Bugs-904474 ] File read of Chinese utf-16-le treats upper byte 1A as EOF Message-ID: Bugs item #904474, was opened at 2004-02-25 11:30 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Ron Rother (rrother) Assigned to: Nobody/Anonymous (nobody) Summary: File read of Chinese utf-16-le treats upper byte 1A as EOF Initial Comment: Any utf-16-le Chinese character with 1A as the most significant byte causes remainder of file to be ignored. code extract: (utf16_encoder, utf16_decoder, utf16_reader, utf16_writer) = codecs.lookup("utf-16-le") ifile = utf16_reader(open(sys.argv[1],"r")) t=ifile.read() When the Chinese character 1A 5C (尚) is encoundered, everthing from the 5C is discarded. These 3 lines: English="You have not selected any books!" Context=1,[MsgBox "You have not selected any books!"] Chinese(Simplified)="尚未选择任何书卷！" are input as: English="You have not selected any books!" Context=1,[MsgBox "You have not selected any books!"] Chinese(Simplified)=" ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 18:19 Message: Logged In: YES user_id=33168 MAL, this seems to come up from time to time. Perhaps we should update the doc for open()? If it's already documented, could we make it clearer? Then we should be able to close this bug. I think I saw another bug recently that was similar to this one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 14:53 Message: Logged In: YES user_id=38388 I believe there is a misconception here: the open(..., "r") will cause the file to be opened in C lib's text mode. Since UTF-16 is binary data, this will lead to problems with line breaking and file handling in general. You should try: import codecs ifile = codecs.open(filename, 'rb', encoding='utf-16-le') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&group_id=5470 From noreply at sourceforge.net Mon Dec 19 05:47:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 20:47:45 -0800 Subject: [ python-Bugs-971238 ] test_timeout failure on trunk Message-ID: Bugs item #971238, was opened at 2004-06-11 09:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Neal Norwitz (nnorwitz) Summary: test_timeout failure on trunk Initial Comment: On current-CVS trunk, Fedora Core 2: testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (13.3079) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 36.437s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (13.3079) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 20:47 Message: Logged In: YES user_id=33168 Assuming this was a temporary problem or firewall or something else. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 21:14 Message: Logged In: YES user_id=33168 Anthony, ping? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-06 17:27 Message: Logged In: YES user_id=80475 Anthony, is this still a valid report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971238&group_id=5470 From noreply at sourceforge.net Mon Dec 19 05:57:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 20:57:04 -0800 Subject: [ python-Bugs-1045509 ] Problems with os.system and ulimit -f Message-ID: Bugs item #1045509, was opened at 2004-10-12 08:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1045509&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Neal Norwitz (nnorwitz) Summary: Problems with os.system and ulimit -f Initial Comment: Python version (running under Fedora Core 2 Linux): Python 2.3.3 (#1, May 7 2004, 10:31:40) [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2 --------------------------------------------------------------------------- I found a problem while executing the 'ulimit -f' bash command within the 'os.system' function. According to the documentation this function should behave exactly like the stdlib function 'system'. However it does not happen as illustrated by the minimal Python and C examples: testsystem.py and testsystem.c (see attached zipped file). In these examples 'largefile' is a compiled C program which writes an endless file into the stdout (also attached). The C program testsystem.c works as expected and prints the following output: command: ulimit -f 10; largefile > xxx; result = 153 The Python program testsystem.py **does not stop**; if interrupted by Ctrl-C it prints: command: ulimit -f 10; largefile > xxx; result = 0 In both cases the output file 'xxx' has 10240 bytes, ie, 10 blocks as limited by 'ulimit'. It is interesting though that the command 'ulimit -t 1' (CPU time) produces correct results under both Python and C versions, ie, interrupts the execution and prints: command: ulimit -t 1; largefile > xxx; result = 137 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 20:57 Message: Logged In: YES user_id=33168 I don't know how to improve this, so closing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 23:35 Message: Logged In: YES user_id=33168 It's set in Python/pythonrun.c. The reason is below. I'm not sure this can be changed. Any suggestions? I'd be happy to update doc, but have no idea where. revision 2.160 date: 2002/04/23 20:31:01; author: jhylton; state: Exp; lines: +3 -0 Ignore SIGXFSZ. The SIGXFSZ signal is sent when the maximum file size limit is exceeded (RLIMIT_FSIZE). Apparently, it is also sent when the 2GB file limit is reached on platforms without large file support. The default action for SIGXFSZ is to terminate the process and dump core. When it is ignored, the system call that caused the limit to be exceeded returns an error and sets errno to EFBIG. Python always checks errno on I/O syscalls, so there is nothing to do with the signal. ---------------------------------------------------------------------- Comment By: Gustavo Sverzut Barbieri (gsbarbieri) Date: 2004-11-26 11:38 Message: Logged In: YES user_id=511989 The problem is that python ignores the SIGXFSZ (File size limit exceeded) signal. import signal signal.signal( signal.SIGXFSZ, signal.SIG_DFL ) solves your problem. Any python developer: why does python ignores this signal? ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-10-22 04:52 Message: Logged In: YES user_id=185428 I also tested the new version "Python 2.4b1" -- the problem still occurs :-(. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1045509&group_id=5470 From noreply at sourceforge.net Mon Dec 19 06:03:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 21:03:51 -0800 Subject: [ python-Bugs-1054615 ] import.c bug when getting mod time fails Message-ID: Bugs item #1054615, was opened at 2004-10-26 07:17 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054615&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Neal Norwitz (nnorwitz) Summary: import.c bug when getting mod time fails Initial Comment: This is current CVS Python. Sorry, no idea what caused this; it started within the last day (or two at the most): C:\Code\python\PCbuild>python_d ..\lib\test\test_traceb ack.py test_bug737473 (__main__.TracebackCases) ... ERROR test_caret (__main__.TracebackCases) ... ok test_nocaret (__main__.TracebackCases) ... ok ========================================== ============================ ERROR: test_bug737473 (__main__.TracebackCases) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "..\lib\test\test_traceback.py", line 62, in test_bug737473 import test_bug737473 SystemError: NULL result without error in PyObject_Call ------------------------------------------------------ ---------------- Ran 3 tests in 0.078s FAILED (errors=1) Traceback (most recent call last): File "..\lib\test\test_traceback.py", line 90, in ? test_main() File "..\lib\test\test_traceback.py", line 86, in test_main run_unittest(TracebackCases) File "C:\Code\python\lib\test\test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "C:\Code\python\lib\test\test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "..\lib\test\test_traceback.py", line 62, in test_bug737473 import test_bug737473 SystemError: NULL result without error in PyObject_Call [12133 refs] C:\Code\python\PCbuild> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 21:03 Message: Logged In: YES user_id=33168 load_source_module() sets an error now. Assuming everything is working as it should. Tim, re-open if there's any work left to do on this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 20:30 Message: Logged In: YES user_id=31435 FYI, any value passed to utime less than 18000 causes the problem on my box, and I bet it's not a coincidence that I'm currently 5 hours (18000 seconds) west of the prime meridian. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 19:36 Message: Logged In: YES user_id=31435 Changed the description to match current reality, and changed group to Python 2.3 (the import.c bug is an old bug). I don't intend to work on it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 19:34 Message: Logged In: YES user_id=31435 Reduced priority to 5 (default). Papered over the bug by passing sane values to os.utime() in the new test code. The underlying import.c bug is still there. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 19:20 Message: Logged In: YES user_id=31435 Looks damn complicated. In import.c, load_source_module() returns NULL if PyOS_GetLastModificationTime() returns -1. But PyOS_GetLastModificationTime() doesn't set any exception when it does return -1. This NULL then propagates all the way back to PyObject_Call(), which produces the SystemError I see. So there's at least a bug in load_source_module() here -- it can't return NULL without setting an exception. I don't yet know why PyOS_GetLastModificationTime() returns -1 in this test case. I suspect it's because the (0,0) passed to utime() doesn't make much sense. I don't get the error if I force it to take the time.sleep() path instead. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 19:15 Message: Logged In: YES user_id=31435 I'm on WinXP Pro SP2. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-10-26 18:55 Message: Logged In: YES user_id=55188 I failed to reproduce the problem in FreeBSD, Windows XP and Linux. What's your platform testing in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 18:44 Message: Logged In: YES user_id=31435 Reduced the priority, because test_bug737473() raises the same SystemError under the released Python 2.3.4 on my box -- it's not a new problem. OTOH, we can't release 2.4 with a standard test that fails on a major platform either. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 08:14 Message: Logged In: YES user_id=31435 Sorry to hear that -- I can't make time to dig. I blew away everything and recompiled from scratch, and the problem didn't go away. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-10-26 07:51 Message: Logged In: YES user_id=6656 "Works for me" (linux). Something Windows specific? The obviously suspicious recent change is patch #737473 which perky checked in yesterday -- but that was a pure Python change, so there must be something more to it than that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 07:19 Message: Logged In: YES user_id=31435 Noting that I also see this failure in a release build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054615&group_id=5470 From noreply at sourceforge.net Mon Dec 19 06:08:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 21:08:53 -0800 Subject: [ python-Bugs-1062708 ] pwent objects from the pwd module ar e not pickle-able Message-ID: Bugs item #1062708, was opened at 2004-11-08 14:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1062708&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Keith Dart (kdart) >Assigned to: Neal Norwitz (nnorwitz) Summary: pwent objects from the pwd module ar e not pickle-able Initial Comment: cPickle.PicklingError: Can't pick le : attribute lookup pwd.struct_passwd failed There seems to be some name discrepancy in the pwd module, and the pickling of a struct_passwd fails. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 21:08 Message: Logged In: YES user_id=33168 Works for me. Reopen if you still have problems. >>> import pickle, cPickle, pwd >>> n = pwd.getpwnam('nobody') >>> n ('nobody', 'x', 65534, 65534, 'nobody', '/', '/bin/false') >>> type(n) >>> pickle.dumps(n) "cpwd\nstruct_passwd\np0\n((S'nobody'\np1\nS'x'\np2\nI65534\nI65534\nS'nobody'\np3\nS'/'\np4\nS'/bin/false'\np5\ntp6\n(dp7\ntp8\nRp9\n." >>> cPickle.dumps(n) "cpwd\nstruct_passwd\np1\n((S'nobody'\np2\nS'x'\nI65534\nI65534\nS'nobody'\np3\nS'/'\nS'/bin/false'\np4\nt(dtRp5\n." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1062708&group_id=5470 From noreply at sourceforge.net Mon Dec 19 06:10:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 21:10:44 -0800 Subject: [ python-Bugs-1066545 ] SegFault in interactive mode when cursor is over a non-ASCII Message-ID: Bugs item #1066545, was opened at 2004-11-15 01:31 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: theIgel (theigel) >Assigned to: Neal Norwitz (nnorwitz) Summary: SegFault in interactive mode when cursor is over a non-ASCII Initial Comment: I'm running python2.3.3 as shipped with Mandrake 10.0 Official. Locale is ru_RU (KOI8-R). When running python in intercative mode (tested in KDE's Konsole and Xterm), I get SegFault each time I press almost any key while a cyrillic character is under cursor. Say, I type: >>> s = 'что за черт' Then I move the cursor using arrow keys somewhere to the middle of the string. Now if I press a letter (no matter english or russian keymap being active) or backspace, or maybe other keys, the interpreter crashes. The arrow keys themselves are working without problems. It doesn't happen if an ASCII character is under cursor. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 21:10 Message: Logged In: YES user_id=33168 Is this still a problem? Can anyone reproduce? If we don't hear back within a month, this should be closed. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-11-16 06:36 Message: Logged In: YES user_id=55188 It seems to work for me for same input on ru_RU.KOI8-R locale. My terminal app is gnome-terminal and tested platforms are: - FreeBSD 5.3 with readline 4.3 - Debian stable with readline 4.2a - Debian testing with readline 4.3 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-16 00:40 Message: Logged In: YES user_id=6656 Hrm. Maybe it's not a readline bug then. OTOH, I've not heard of a Python bug like this either. Do you know how to use gdb? (It's possible that bash uses its own version of readline). ---------------------------------------------------------------------- Comment By: theIgel (theigel) Date: 2004-11-15 06:39 Message: Logged In: YES user_id=1151790 libreadline4-4.3-7mdk So it's 4.3 But if it were a readline bug, wouldn't it mean it should appear in other console applications? It doesn't, at least in shell. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-15 06:18 Message: Logged In: YES user_id=6656 Ask Mandrake. Mandrake is rpm-based, right? So rpm -q readline should work. ---------------------------------------------------------------------- Comment By: theIgel (theigel) Date: 2004-11-15 04:37 Message: Logged In: YES user_id=1151790 How can I find out readline version? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-15 01:37 Message: Logged In: YES user_id=6656 What version of readline? I don't think this is going to be a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066545&group_id=5470 From noreply at sourceforge.net Mon Dec 19 07:06:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 22:06:44 -0800 Subject: [ python-Bugs-1072182 ] bad arg type to isspace in struct module Message-ID: Bugs item #1072182, was opened at 2004-11-23 15:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072182&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg McFarlane (gregm) >Assigned to: Neal Norwitz (nnorwitz) Summary: bad arg type to isspace in struct module Initial Comment: For characters greater than 0x7f, the calls to isspace() in Modules/structmodule.c can return random values. For example, on Solaris I got this (incorrect) output: >>> import struct >>> struct.calcsize('10d\xfed') 88 >>> After changing the three occurrences of "isspace((int)c)" to "isspace((unsigned char)c)", this was the (correct) output: >>> import struct >>> struct.calcsize('10d\xfed') Traceback (most recent call last): File "", line 1, in ? struct.error: bad char in struct format >>> Reason: the '\xfe' is taken as a signed char. The code (int)c converts this to a signed int (-2). The system isspace macro uses this as an index into the __ctype array. The array is only defined for the values 0 to 255 and so -2 is out-of-bounds. The value returned by isspace depends on what happens to be at that location in memory. NOTE: There may be other occurrences of this bug in other parts of the python code. Please check. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 22:06 Message: Logged In: YES user_id=33168 Committed revision 41768. (for 2.5) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 01:06 Message: Logged In: YES user_id=80475 Fixed the ones in the struct module. Leaving this report open for someone with time to investigate other occurrences. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2004-11-23 20:52 Message: Logged In: YES user_id=265183 Looking at other instances of isspace and friends, I think this is the point of calling Py_CHARMASK, which is used to "Convert a possibly signed character to a nonnegative int" (depending on whether 'char' is signed or unsigned). In other words, I believe the three instances of isspace((int)c) in Modules/structmodule.c should be changed to isspace(Py_CHARMASK(c)). `grep isspace */*.c | grep -v CHARMASK` suggests some other potential bugs: - Modules/posixmodule.c:466 (os2_formatmsg): isspace(*lastc) - Modules/socketmodule.c:504 (set_error): isspace(*lastc) `egrep 'isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower|isprint|isprint|ispunct|isupper|isxdigit' */*.c | grep -v Py_CHARMASK` suggest the following further bugs: - Modules/_hotshot.c:1431 (get_version_string): isdigit((int)*rev) [unlikely to cause trouble, but wrong in the same way...] - Modules/_tkinter.c:639 (Tkapp_New): isupper((int)argv0[0]) - Modules/pyexpat.c:1800 (get_version_string): isdigit((int)*rev) [again unlikely a problem] - Modules/stropmodule.c:760 (strop_atoi): isalnum((int)end[-1]) ye - Parser/grammar.c:183 (translabel): isalpha((int)(lb->lb_str[1])) - Parser/tokenizer.c:232 (get_coding_spec): isalnum((int)t[0]) - Parser/atof.c:16 (atof): (c = *s++) != '\0' && isdigit(c) [same problem appears three times in the same function] - Python/compile.c:1721,1727 (parsestr): int quote = *s; ... isalpha(quote) - Python/dynload_aix.c:147 (aix_loaderror): isdigit(*message[i]) - Python/getargs.c:141 (vgetargs1): int c = *format++ (and later, isalpha(c)) - Python/getargcs.c:258 (vgetargs1): isalpha((int)(*format)) - Python/getargs.c:336 (converttuple): int c = *format++ (and later, isalpha(c)) - Python/getargs.c:1222 (vgetargskeyword): i = *format++ (and later, isalpha(i)) That's all that I could find. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072182&group_id=5470 From noreply at sourceforge.net Mon Dec 19 07:15:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 22:15:10 -0800 Subject: [ python-Bugs-1084766 ] sys.stdin segfaults on invalid stdin Message-ID: Bugs item #1084766, was opened at 2004-12-13 15:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 6 Submitted By: Mihai Ibanescu (misa) >Assigned to: Neal Norwitz (nnorwitz) Summary: sys.stdin segfaults on invalid stdin Initial Comment: Bug reported as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140715 If stdin is invalid (e.g., redirected from a directory by mistake), python interpreter segfaults on any attempt to access it. In a case where one actually tries to read sys.stdin, I would expect something like Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 22:15 Message: Logged In: YES user_id=33168 This was fixed a while ago for 2.4.3 and 2.5. See bug 1353504 ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-01-11 18:16 Message: Logged In: YES user_id=51702 A trivial solution is to move the lines _PyExc_Init(); _PyImport_FixupExtensions("exceptions", "exceptions"); above the block that begins with "sysmod = _PySys_Init();" Then when the interpreter is run with "python < ." it outputs: Fatal Python error: Py_Initialize: can't initialize sys Avbruten (SIGABRT) I don't know if that is a good solution. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-12-18 19:25 Message: Logged In: YES user_id=2772 Duplicated here on a stale CVS version of 2.4. Here's some information from gdb: Starting program: /usr/src/cvs/python/dist/src/python -S -c '' < / [Thread debugging using libthread_db enabled] [New Thread -151074304 (LWP 6154)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151074304 (LWP 6154)] 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 549 Py_INCREF(value); (gdb) where #0 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 #1 0x08075e13 in PyDict_SetItemString (v=0xf6fae79c, key=0x8109d60 "stdin", item=0x0) at Objects/dictobject.c:1988 #2 0x080d6988 in _PySys_Init () at Python/sysmodule.c:961 #3 0x080d3e17 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:190 #4 0x080d5815 in Py_Initialize () at Python/pythonrun.c:283 #5 0x08055159 in Py_Main (argc=4, argv=0xfefac1b4) at Modules/main.c:418 #6 0x08054e0f in main (argc=4, argv=0xfefac1b4) at Modules/python.c:23 The problem seems to be that PyFile_FromFile() returns NULL without tripping the PyErr_Occurred() test on my line 946 of sysmodule.c, because the call to fill_file_fields() returns NULL too. It looks like fill_file_fields is supposed to return NULL with an error set, but when dircheck() is called that early, PyExc_IOError is NULL, so no error is set. Maybe _PyExc_Init() must be moved earlier in startup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 From noreply at sourceforge.net Mon Dec 19 10:05:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 01:05:30 -0800 Subject: [ python-Bugs-1385004 ] exec statement link in index broken Message-ID: Bugs item #1385004, was opened at 2005-12-19 09:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385004&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: exec statement link in index broken Initial Comment: In library reference index: http://www.python.org/doc/2.4.2/lib/genindex.html "exec statement" points to http://www.python.org/doc/2.4.2/lib/bltin-code-objects.html#l2h-265 Which seems wrong. (2.4 docs already had the same). -Harri ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385004&group_id=5470 From noreply at sourceforge.net Mon Dec 19 10:58:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 01:58:07 -0800 Subject: [ python-Bugs-1385040 ] compiler module does not detect a syntax error Message-ID: Bugs item #1385040, was opened at 2005-12-19 09: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=1385040&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: compiler module does not detect a syntax error Initial Comment: import compiler compiler.parse("def foo(a=1,b): pass") Gives: Module(None, Stmt([Function(None, 'foo', ['a', 'b'], [Const(1)], 0, None, Stmt([Pass()]))])) However, the python interpreter itself barks for the same code: SyntaxError: non-default argument follows default argument -Harri ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470 From noreply at sourceforge.net Mon Dec 19 11:15:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 02:15:23 -0800 Subject: [ python-Bugs-1385055 ] execfile anomaly with "from __future__ import division" Message-ID: Bugs item #1385055, was opened at 2005-12-19 10: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=1385055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: execfile anomaly with "from __future__ import division" Initial Comment: If I have a file init.py with two lines: from __future__ import division print 3/4 and I do [harri at dell-harri tests]$ python Python 2.4 (#1, Feb 16 2005, 01:23:25) [GCC 3.4.3 (Mandrakelinux 10.0 3.4.3-2mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> execfile('init.py') 0.75 >>> 3/4 0 I would have expected the latter to return 0.75 as well. Due to this it seems impossible to provide init code that would initialize the interactive prompt to future division behaviour. The same applies to exec statement. I'm not sure if this is bug, or an unfortunate feature. The documention is not very clear on this issue. -Harri ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470 From noreply at sourceforge.net Mon Dec 19 11:42:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 02:42:07 -0800 Subject: [ python-Bugs-1385055 ] execfile anomaly with "from __future__ import division" Message-ID: Bugs item #1385055, was opened at 2005-12-19 10:15 Message generated for change (Comment added) made by harripasanen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: execfile anomaly with "from __future__ import division" Initial Comment: If I have a file init.py with two lines: from __future__ import division print 3/4 and I do [harri at dell-harri tests]$ python Python 2.4 (#1, Feb 16 2005, 01:23:25) [GCC 3.4.3 (Mandrakelinux 10.0 3.4.3-2mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> execfile('init.py') 0.75 >>> 3/4 0 I would have expected the latter to return 0.75 as well. Due to this it seems impossible to provide init code that would initialize the interactive prompt to future division behaviour. The same applies to exec statement. I'm not sure if this is bug, or an unfortunate feature. The documention is not very clear on this issue. -Harri ---------------------------------------------------------------------- >Comment By: Harri Pasanen (harripasanen) Date: 2005-12-19 10:42 Message: Logged In: YES user_id=77088 Looks like this is a duplicate of [ 567568 ] future division broken w/ PYTHONSTARTUP http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=567568 As I suspected, it is an unfortunate feature. Tim's explication provides the missing documentation. And I assume the exec statement provides its own anonymous module. Btw. where is the -Qnew documented? from __future__ division docs should carry a pointer to it. Here is another thread on the subject in the ipython mailing list: http://scipy.net/pipermail/ipython-user/2005-December/001183.html This can be closed. -Harri ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470 From noreply at sourceforge.net Mon Dec 19 16:25:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 07:25:55 -0800 Subject: [ python-Bugs-1382740 ] len() on class broken Message-ID: Bugs item #1382740, was opened at 2005-12-16 13:18 Message generated for change (Comment added) made by kquick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Guido van Rossum (gvanrossum) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. ---------------------------------------------------------------------- >Comment By: Kevin Quick (kquick) Date: 2005-12-19 08:25 Message: Logged In: YES user_id=6133 This bug *may* be related to Bug#1066490 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-16 21:40 Message: Logged In: YES user_id=80475 Guido, this issue arises throughout the language in various guises (for instance, it applies to __neg__ as well as __len__). It comes-up whenever built-in functions or operators bypass attribute lookup in favor of direct slot access. Much of the code in abstract.c is in the form: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) raise TypeError If we cared about this (and I'm not sure we do), the solution is to make the abstract.c functions smarter: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) try: f = gettattr(o, 'somefunc') except AttributeError: raise TypeError else: return f() The advantage of the change is restoring the symmetry between len(o) and o.__len__() where the method definition is available via attribute lookup but not via a slot. The thought is to keep the speedy access as default, but if that fails, then do a normal attribute lookup before barfing back an error message. This is precedent for this solution elsewhere in the codebase (though I don't remember where at the moment). OTOH, I'm not sure we care. pervades the code in abstract.c which is in the form: def PyObject_Size ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2005-12-16 15:52 Message: Logged In: YES user_id=6133 That would indeed solve '4', but has a non-orthogonality of attribute propagation that I don't understand and which seems inconsistent. In my original: '1' demonstrates that __len__ is indeed in the dictionary for the class. '2' shows the expected attribute propagation effects: if at attribute is not found in the instance dictionary, the class dictionary is checked. '3' shows that len is implemented (generally) by looking for a __len__ method on the object in question. '4' confuses me, because it means that '3' isn't quite correct... With your metaclass solution (using "__metaclass__ = meta" :) it does indeed make '4' work, and '1', but '2' and '3' now do not work, showing that instance-->class propagation does not follow instance-->class-->metaclass. Or something ... Approaching this a different way: My understanding of @classmethod (or perhaps more properly @staticmethod) is that it allows "constant" methods that are independent of the particular object instance. So if I had: class C: @staticmethod def f(): return 1 then both C.f() and C().f() are valid and return 1. Why the len() translation to __len__ works *differently* is strange. I'm still defining a method, just one that I want Python to use for any len(A) or len(A()) refs, translating those to A.__len__() or A().__len__() and using those just as for C and f, respectively. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 14:43 Message: Logged In: YES user_id=1188172 You want to use a metaclass: class meta(type): def __len__(cls): return 12 class B: __metaclass__ = B print len(B) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 From noreply at sourceforge.net Mon Dec 19 20:42:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 11:42:13 -0800 Subject: [ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c Message-ID: Bugs item #970334, was opened at 2004-06-10 12:46 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:42 Message: Logged In: YES user_id=6606 I'm seeing this exact problem compiling Python 2.4.2 on Solaris 10. I've got the following gcc-related packages installed: SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49 SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49 SUNWgccruntime - runtime libraries (also?), 11.10.0,REV=2005.01.08.05.16 $ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL' /usr/include/iso/math_c99.h:#undef HUGE_VAL /usr/include/iso/math_c99.h:#define HUGE_VAL __builtin_huge_val A quick look around didn't tell me what __builtin_huge_val is defined to. printf()'ing HUGE_VAL from a test.c proggie shows the following: e=0.000000e+00, f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 11:00 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-10 15:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 From noreply at sourceforge.net Mon Dec 19 20:52:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 11:52:35 -0800 Subject: [ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c Message-ID: Bugs item #970334, was opened at 2004-06-10 12:46 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:52 Message: Logged In: YES user_id=6606 Oops, forgot an arg -- HUGE_VAL is defined as the following on Solaris 10: e=Inf f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:42 Message: Logged In: YES user_id=6606 I'm seeing this exact problem compiling Python 2.4.2 on Solaris 10. I've got the following gcc-related packages installed: SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49 SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49 SUNWgccruntime - runtime libraries (also?), 11.10.0,REV=2005.01.08.05.16 $ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL' /usr/include/iso/math_c99.h:#undef HUGE_VAL /usr/include/iso/math_c99.h:#define HUGE_VAL __builtin_huge_val A quick look around didn't tell me what __builtin_huge_val is defined to. printf()'ing HUGE_VAL from a test.c proggie shows the following: e=0.000000e+00, f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 11:00 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-10 15:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 From noreply at sourceforge.net Mon Dec 19 21:52:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 12:52:39 -0800 Subject: [ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c Message-ID: Bugs item #970334, was opened at 2004-06-10 12:46 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 20:52 Message: Logged In: YES user_id=6606 As noted by some other people on the web, defining Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which is defined as MAXFLOAT on Solaris), a successful compile can be achieved. If I explicitly #define Py_HUGE_VAL to __builtin_huge_val, I get the same compilation error as reported by this bug. Removing optimization flags does not help. The HUGE_VAL provided by Solaris 10 doesn't seem to be a workable value for pyport.h's macro. My little test proggie was missing yet more args, so I'm posting both the source and output this time. --- snip --- #include int main(char **argv) { #ifdef SOLARIS printf("SOLARIS=%e\n", SOLARIS); #endif printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT); printf("HUGE: e=%e, f=%f\n", HUGE, HUGE); printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL); } --- snip --- Output: MAXFLOAT: e=3.402823e+38, f=340282346638528859811704183484516925440.000000 HUGE: e=3.402823e+38, f=340282346638528859811704183484516925440.000000 HUGE_VAL: e=Inf, f=Inf ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:52 Message: Logged In: YES user_id=6606 Oops, forgot an arg -- HUGE_VAL is defined as the following on Solaris 10: e=Inf f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:42 Message: Logged In: YES user_id=6606 I'm seeing this exact problem compiling Python 2.4.2 on Solaris 10. I've got the following gcc-related packages installed: SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49 SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49 SUNWgccruntime - runtime libraries (also?), 11.10.0,REV=2005.01.08.05.16 $ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL' /usr/include/iso/math_c99.h:#undef HUGE_VAL /usr/include/iso/math_c99.h:#define HUGE_VAL __builtin_huge_val A quick look around didn't tell me what __builtin_huge_val is defined to. printf()'ing HUGE_VAL from a test.c proggie shows the following: e=0.000000e+00, f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 11:00 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-10 15:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 From noreply at sourceforge.net Mon Dec 19 22:19:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 13:19:56 -0800 Subject: [ python-Bugs-837046 ] pyport.h redeclares gethostname() if SOLARIS is defined Message-ID: Bugs item #837046, was opened at 2003-11-06 08:09 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Bostock (jbostock) Assigned to: Nobody/Anonymous (nobody) Summary: pyport.h redeclares gethostname() if SOLARIS is defined Initial Comment: The file pyport.h contains the lines: #ifdef SOLARIS /* Unchecked */ extern int gethostname(char *, int); #endif However, Solaris already defines gethostname() in /usr/include/unistd.h [I only have access to Solaris 2.6 and 2.8 so I can't vouch for other versions]. This in iteself is not a problem. However, under Python2.3, pyconfig.h defines _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED which cause (indirectly) the following prototype to be selected from unitstd.h: extern int gethostname(char *, size_t); Since size_t is an unsigned char, a compiler error message is generated (both by the native compiler and gcc) saying that the function has been redefined. This means that no python program can be compiled if SOLARIS is #defined. I imagine that the above code from pyport.h is only applicable to an earlier version of Solaris than 2.6, and so should either be removed or qualified somehow. ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 21:19 Message: Logged In: YES user_id=6606 I can verify this issue on Solaris 10 (SunOS 5.10). Not only does this code seem unnecessary, but there is no configury nor make magic which _can_ ever set the SOLARIS preprocessor define. If I run 'make' as follows, I can trigger a hard compilation error: [Python-2.4.2]$ make CFLAGS='$(BASECFLAGS) $(OPT) -DSOLARIS=true' ... In file included from ./Include/Python.h:55, from Objects/complexobject.c:8: ./Include/pyport.h:382: error: conflicting types for 'gethostname' /usr/include/unistd.h:319: error: previous declaration of 'gethostname' was here./Include/pyport.h:382: error: conflicting types for 'gethostname' /usr/include/unistd.h:319: error: previous declaration of 'gethostname' was here*** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I recommend removing this snippet from pyport.h: --- Include/pyport.h (revision 41772) +++ Include/pyport.h (working copy) @@ -372,11 +372,6 @@ in platform-specific #ifdefs. **************************************************************************/ -#ifdef SOLARIS -/* Unchecked */ -extern int gethostname(char *, int); -#endif - #ifdef __BEOS__ /* Unchecked */ /* It's in the libs, but not the headers... - [cjh] */ ---------------------------------------------------------------------- Comment By: James Bostock (jbostock) Date: 2003-11-26 18:43 Message: Logged In: YES user_id=902503 "Since size_t is an unsigned char" should read "Since size_t is an unsigned int". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837046&group_id=5470 From noreply at sourceforge.net Mon Dec 19 23:01:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 14:01:21 -0800 Subject: [ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Message-ID: Bugs item #1276509, was opened at 2005-08-30 10:48 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 22:01 Message: Logged In: YES user_id=6606 This is a duplicate of issue #970334, which I just submitted a patch to python-dev for. ---------------------------------------------------------------------- Comment By: csmuc (chrschaffer) Date: 2005-09-28 06:54 Message: Logged In: YES user_id=1337267 Hi all, I found a newsgroup posting which adviced to change a line in Include/pyport.h http://mail.python.org/pipermail/patches/2005-February/016881.html ---------------8<----------------------------------------------------- The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define Py_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h --------------->8----------------------------------------------------- I did as adviced and the compile worked. I am not sure, if this is a valid solution, but at least it?s a workaround. Thanks to Reinhold Birkenfeld for your hint! Regards, Chris ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 07:03 Message: Logged In: YES user_id=1188172 Looks like HUGE_VAL is defined in a curious way on your platform. Can you find out what header defines HUGE_VAL and to what it expands? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 From noreply at sourceforge.net Mon Dec 19 23:02:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 14:02:19 -0800 Subject: [ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c Message-ID: Bugs item #970334, was opened at 2004-06-10 12:46 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 22:02 Message: Logged In: YES user_id=6606 Issue #1276509 is a duplicate of this issue. I've just submitted a patch to the python-dev list for this problem, which I'll attach below (and expect Tracker to mangle): Index: configure.in =================================================================== --- configure.in (revision 41772) +++ configure.in (working copy) @@ -215,6 +215,17 @@ fi +# See the #define for Py_HUGE_VAL in pyport.h. +case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + # Solaris 10's /usr/include/iso/math_c99.h defines HUGE_VAL as + # __builtin_huge_val, which causes problems when defining Py_HUGE_VAL. + AC_DEFINE(Py_HUGE_VAL, HUGE, + Define to a positive double which represents infinity) + ;; +esac + + # # SGI compilers allow the specification of the both the ABI and the # ISA on the command line. Depending on the values of these switches, ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 20:52 Message: Logged In: YES user_id=6606 As noted by some other people on the web, defining Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which is defined as MAXFLOAT on Solaris), a successful compile can be achieved. If I explicitly #define Py_HUGE_VAL to __builtin_huge_val, I get the same compilation error as reported by this bug. Removing optimization flags does not help. The HUGE_VAL provided by Solaris 10 doesn't seem to be a workable value for pyport.h's macro. My little test proggie was missing yet more args, so I'm posting both the source and output this time. --- snip --- #include int main(char **argv) { #ifdef SOLARIS printf("SOLARIS=%e\n", SOLARIS); #endif printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT); printf("HUGE: e=%e, f=%f\n", HUGE, HUGE); printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL); } --- snip --- Output: MAXFLOAT: e=3.402823e+38, f=340282346638528859811704183484516925440.000000 HUGE: e=3.402823e+38, f=340282346638528859811704183484516925440.000000 HUGE_VAL: e=Inf, f=Inf ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:52 Message: Logged In: YES user_id=6606 Oops, forgot an arg -- HUGE_VAL is defined as the following on Solaris 10: e=Inf f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:42 Message: Logged In: YES user_id=6606 I'm seeing this exact problem compiling Python 2.4.2 on Solaris 10. I've got the following gcc-related packages installed: SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49 SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49 SUNWgccruntime - runtime libraries (also?), 11.10.0,REV=2005.01.08.05.16 $ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL' /usr/include/iso/math_c99.h:#undef HUGE_VAL /usr/include/iso/math_c99.h:#define HUGE_VAL __builtin_huge_val A quick look around didn't tell me what __builtin_huge_val is defined to. printf()'ing HUGE_VAL from a test.c proggie shows the following: e=0.000000e+00, f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 11:00 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-10 15:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 From noreply at sourceforge.net Mon Dec 19 23:12:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 14:12:52 -0800 Subject: [ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c Message-ID: Bugs item #970334, was opened at 2004-06-10 07:46 Message generated for change (Comment added) made by lonebandit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff ---------------------------------------------------------------------- >Comment By: JD Bronson (lonebandit) Date: 2005-12-19 16:12 Message: Logged In: YES user_id=257991 This is too old to deal with any more. I had forgot I reported this. Using 2.4.2 under Solaris with Studio 11 builds fine out of the box: Python 2.4.2 (#1, Dec 12 2005, 19:14:42) [C] on sunos5 -JD ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 16:02 Message: Logged In: YES user_id=6606 Issue #1276509 is a duplicate of this issue. I've just submitted a patch to the python-dev list for this problem, which I'll attach below (and expect Tracker to mangle): Index: configure.in =================================================================== --- configure.in (revision 41772) +++ configure.in (working copy) @@ -215,6 +215,17 @@ fi +# See the #define for Py_HUGE_VAL in pyport.h. +case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + # Solaris 10's /usr/include/iso/math_c99.h defines HUGE_VAL as + # __builtin_huge_val, which causes problems when defining Py_HUGE_VAL. + AC_DEFINE(Py_HUGE_VAL, HUGE, + Define to a positive double which represents infinity) + ;; +esac + + # # SGI compilers allow the specification of the both the ABI and the # ISA on the command line. Depending on the values of these switches, ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 14:52 Message: Logged In: YES user_id=6606 As noted by some other people on the web, defining Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which is defined as MAXFLOAT on Solaris), a successful compile can be achieved. If I explicitly #define Py_HUGE_VAL to __builtin_huge_val, I get the same compilation error as reported by this bug. Removing optimization flags does not help. The HUGE_VAL provided by Solaris 10 doesn't seem to be a workable value for pyport.h's macro. My little test proggie was missing yet more args, so I'm posting both the source and output this time. --- snip --- #include int main(char **argv) { #ifdef SOLARIS printf("SOLARIS=%e\n", SOLARIS); #endif printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT); printf("HUGE: e=%e, f=%f\n", HUGE, HUGE); printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL); } --- snip --- Output: MAXFLOAT: e=3.402823e+38, f=340282346638528859811704183484516925440.000000 HUGE: e=3.402823e+38, f=340282346638528859811704183484516925440.000000 HUGE_VAL: e=Inf, f=Inf ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 13:52 Message: Logged In: YES user_id=6606 Oops, forgot an arg -- HUGE_VAL is defined as the following on Solaris 10: e=Inf f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 13:42 Message: Logged In: YES user_id=6606 I'm seeing this exact problem compiling Python 2.4.2 on Solaris 10. I've got the following gcc-related packages installed: SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49 SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49 SUNWgccruntime - runtime libraries (also?), 11.10.0,REV=2005.01.08.05.16 $ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL' /usr/include/iso/math_c99.h:#undef HUGE_VAL /usr/include/iso/math_c99.h:#define HUGE_VAL __builtin_huge_val A quick look around didn't tell me what __builtin_huge_val is defined to. printf()'ing HUGE_VAL from a test.c proggie shows the following: e=0.000000e+00, f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 06:00 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 16:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-10 10:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 From noreply at sourceforge.net Mon Dec 19 23:19:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 14:19:10 -0800 Subject: [ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c Message-ID: Bugs item #970334, was opened at 2004-06-10 12:46 Message generated for change (Comment added) made by dlr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 22:19 Message: Logged In: YES user_id=6606 But with Python 2.4.2 and GCC 3.4.2 (a perfectly reasonable combination), the build does still fail on Solaris 10. ---------------------------------------------------------------------- Comment By: JD Bronson (lonebandit) Date: 2005-12-19 22:12 Message: Logged In: YES user_id=257991 This is too old to deal with any more. I had forgot I reported this. Using 2.4.2 under Solaris with Studio 11 builds fine out of the box: Python 2.4.2 (#1, Dec 12 2005, 19:14:42) [C] on sunos5 -JD ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 22:02 Message: Logged In: YES user_id=6606 Issue #1276509 is a duplicate of this issue. I've just submitted a patch to the python-dev list for this problem, which I'll attach below (and expect Tracker to mangle): Index: configure.in =================================================================== --- configure.in (revision 41772) +++ configure.in (working copy) @@ -215,6 +215,17 @@ fi +# See the #define for Py_HUGE_VAL in pyport.h. +case $ac_sys_system/$ac_sys_release in + SunOS/5.10) + # Solaris 10's /usr/include/iso/math_c99.h defines HUGE_VAL as + # __builtin_huge_val, which causes problems when defining Py_HUGE_VAL. + AC_DEFINE(Py_HUGE_VAL, HUGE, + Define to a positive double which represents infinity) + ;; +esac + + # # SGI compilers allow the specification of the both the ABI and the # ISA on the command line. Depending on the values of these switches, ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 20:52 Message: Logged In: YES user_id=6606 As noted by some other people on the web, defining Py_HUGE_VAL to some other value (e.g. math.h's HUGE, which is defined as MAXFLOAT on Solaris), a successful compile can be achieved. If I explicitly #define Py_HUGE_VAL to __builtin_huge_val, I get the same compilation error as reported by this bug. Removing optimization flags does not help. The HUGE_VAL provided by Solaris 10 doesn't seem to be a workable value for pyport.h's macro. My little test proggie was missing yet more args, so I'm posting both the source and output this time. --- snip --- #include int main(char **argv) { #ifdef SOLARIS printf("SOLARIS=%e\n", SOLARIS); #endif printf("MAXFLOAT: e=%e, f=%f\n", MAXFLOAT, MAXFLOAT); printf("HUGE: e=%e, f=%f\n", HUGE, HUGE); printf("HUGE_VAL: e=%e, f=%f\n", HUGE_VAL, HUGE_VAL); } --- snip --- Output: MAXFLOAT: e=3.402823e+38, f=340282346638528859811704183484516925440.000000 HUGE: e=3.402823e+38, f=340282346638528859811704183484516925440.000000 HUGE_VAL: e=Inf, f=Inf ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:52 Message: Logged In: YES user_id=6606 Oops, forgot an arg -- HUGE_VAL is defined as the following on Solaris 10: e=Inf f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Daniel L. Rall (dlr) Date: 2005-12-19 19:42 Message: Logged In: YES user_id=6606 I'm seeing this exact problem compiling Python 2.4.2 on Solaris 10. I've got the following gcc-related packages installed: SFWgcc34 - gcc itself, 3.4.2,REV=2005.01.05.17.49 SFWgcc34l - runtime libraries, 3.4.2,REV=2005.01.05.17.49 SUNWgccruntime - runtime libraries (also?), 11.10.0,REV=2005.01.08.05.16 $ find /usr/include/ -type f -print | xargs grep 'HUGE_VAL' /usr/include/iso/math_c99.h:#undef HUGE_VAL /usr/include/iso/math_c99.h:#define HUGE_VAL __builtin_huge_val A quick look around didn't tell me what __builtin_huge_val is defined to. printf()'ing HUGE_VAL from a test.c proggie shows the following: e=0.000000e+00, f=-68919433614220753064658744755535637868839108989653165135689455360011087079981720250557282791129967457227152890098055305015702110410402373120932263772837419450856325178283131823339151685653290667717623259822988338292772963105424367682944480240667451651976397620342290533347097094299868383451266824678670336.000000 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 11:00 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-10 15:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 From noreply at sourceforge.net Tue Dec 20 12:10:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 03:10:02 -0800 Subject: [ python-Bugs-1383644 ] MacOS.WMAvailable() doesn't launch Python.app properly Message-ID: Bugs item #1383644, was opened at 2005-12-17 17:12 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1383644&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: MacOS.WMAvailable() doesn't launch Python.app properly Initial Comment: Running the following on Apple-installed Python 2.3.5 on OS 10.4.3: ~ has$ pythonw Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MacOS >>> MacOS.WMAvailable() True a Python.app process starts to launch as expected; however its icon remains bouncing indefinitely in the Dock. Additional prodding, e.g.: >>> import Carbon.Evt >>> Carbon.Evt.WaitNextEvent(0,0) (0, (0, 0, 1141622, (751, 225), 128)) causes it to finish launching as expected (Dock icon stops bouncing, small black triangle appears next to it). Third-party has confirmed this problem. Might be a problem with WMAvailable(), might be a problem in Python.app. Don't know enough Carbon to determine this myself. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-12-20 12:10 Message: Logged In: YES user_id=45365 This is not a bug: this is expected behaviour:-) Note that nothing is "launched" by WMavailable() or WaitNextEvent(): the only thing these calls do is signal the existence of pythonw (or actually Python.app) to the window manager. Before WMAvailable() is called the window manager knows nothing about Python.app, so nothing is shown in the dock. WMavailable() causes the very first WM call, which (among other things) make the dock icon appear and start bouncing. The "end of bouncing" happens when the WM notices the app has gone into its event loop, which is indeed signalled by calling WNE() or something similar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1383644&group_id=5470 From noreply at sourceforge.net Tue Dec 20 17:44:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 08:44:04 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-09 02:03 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: ken668 (ken668) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-20 17:44 Message: Logged In: YES user_id=38376 This is not a leak (a leak means that the process will grow if you *repeat* the operation, not that things are unexpectedly left in the object memory). And it's not a bug, either; the "copy" of the message that's returned by get_objects() is the contents of the buffer variable in the test program. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-15 07:44 Message: Logged In: YES user_id=1400763 Yes, it is a bug. My mistake was when I gave the details, I should have mentioned gc.get_objects(), not gc.garbage. gc.get_objects() showed the leaks not gc.garbage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 06:56 Message: Logged In: YES user_id=33168 Do you still believe there is a problem or can this report be closed? ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 17:00 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 16:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 16:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 21:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Tue Dec 20 19:37:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 10:37:56 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 17:03 Message generated for change (Comment added) made by ken668 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: ken668 (ken668) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: ken668 (ken668) Date: 2005-12-20 10:37 Message: Logged In: YES user_id=1400763 May be you did not look at my test program more closely. Please look at the statement msg=None. The should removed all references of the object. The memory will definely grow if you repeat the operation. Why don't you run the email.message_from_string in a loop and see whether the memory grows. Thanks. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-20 08:44 Message: Logged In: YES user_id=38376 This is not a leak (a leak means that the process will grow if you *repeat* the operation, not that things are unexpectedly left in the object memory). And it's not a bug, either; the "copy" of the message that's returned by get_objects() is the contents of the buffer variable in the test program. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-14 22:44 Message: Logged In: YES user_id=1400763 Yes, it is a bug. My mistake was when I gave the details, I should have mentioned gc.get_objects(), not gc.garbage. gc.get_objects() showed the leaks not gc.garbage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:56 Message: Logged In: YES user_id=33168 Do you still believe there is a problem or can this report be closed? ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 08:00 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Tue Dec 20 20:03:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 11:03:02 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-09 02:03 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: ken668 (ken668) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-20 20:03 Message: Logged In: YES user_id=38376 Nope. If you do msg=None, you'll release a reference to the message object, and all direct, non-cyclic members. Any cyclic references held by the message object (or created by the email parser) will be removed at a later time, by the garbage collector. And even if you add an explicit gc.collect() call to your program, that won't remove the contents of the *buffer* variable. (If you run the program in a loop *without* an explicit gc.collect() call, the process will appear to grow for a while, since you're creating objects faster than the GC can remove them. Add gc.collect() to the loop, and the memory use will be rock solid.) ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-20 19:37 Message: Logged In: YES user_id=1400763 May be you did not look at my test program more closely. Please look at the statement msg=None. The should removed all references of the object. The memory will definely grow if you repeat the operation. Why don't you run the email.message_from_string in a loop and see whether the memory grows. Thanks. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-20 17:44 Message: Logged In: YES user_id=38376 This is not a leak (a leak means that the process will grow if you *repeat* the operation, not that things are unexpectedly left in the object memory). And it's not a bug, either; the "copy" of the message that's returned by get_objects() is the contents of the buffer variable in the test program. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-15 07:44 Message: Logged In: YES user_id=1400763 Yes, it is a bug. My mistake was when I gave the details, I should have mentioned gc.get_objects(), not gc.garbage. gc.get_objects() showed the leaks not gc.garbage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 06:56 Message: Logged In: YES user_id=33168 Do you still believe there is a problem or can this report be closed? ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 17:00 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 16:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 16:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 21:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Tue Dec 20 23:11:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 14:11:58 -0800 Subject: [ python-Bugs-1376775 ] Memory leak in the email package Message-ID: Bugs item #1376775, was opened at 2005-12-08 17:03 Message generated for change (Comment added) made by ken668 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: ken668 (ken668) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory leak in the email package Initial Comment: memory leak in email.message_from_string. This is what I did to create a leak. You used the attached file, memleak.eml. f = open("memleak.eml") buffer = f.read() f.close() # now buffer has the email string msg = email.message_from_string(buffer) msg = None # this should free the memory but it doesn't # The memory that is used in msg is not completely free ---------------------------------------------------------------------- >Comment By: ken668 (ken668) Date: 2005-12-20 14:11 Message: Logged In: YES user_id=1400763 I assume the new email package has cyclic references in it. My program has garabage collection disabled because of performance issues. That means the email package will cause memory leak in my program. I will use the old package instead. Thanks for the help. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-20 11:03 Message: Logged In: YES user_id=38376 Nope. If you do msg=None, you'll release a reference to the message object, and all direct, non-cyclic members. Any cyclic references held by the message object (or created by the email parser) will be removed at a later time, by the garbage collector. And even if you add an explicit gc.collect() call to your program, that won't remove the contents of the *buffer* variable. (If you run the program in a loop *without* an explicit gc.collect() call, the process will appear to grow for a while, since you're creating objects faster than the GC can remove them. Add gc.collect() to the loop, and the memory use will be rock solid.) ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-20 10:37 Message: Logged In: YES user_id=1400763 May be you did not look at my test program more closely. Please look at the statement msg=None. The should removed all references of the object. The memory will definely grow if you repeat the operation. Why don't you run the email.message_from_string in a loop and see whether the memory grows. Thanks. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-20 08:44 Message: Logged In: YES user_id=38376 This is not a leak (a leak means that the process will grow if you *repeat* the operation, not that things are unexpectedly left in the object memory). And it's not a bug, either; the "copy" of the message that's returned by get_objects() is the contents of the buffer variable in the test program. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-14 22:44 Message: Logged In: YES user_id=1400763 Yes, it is a bug. My mistake was when I gave the details, I should have mentioned gc.get_objects(), not gc.garbage. gc.get_objects() showed the leaks not gc.garbage. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:56 Message: Logged In: YES user_id=33168 Do you still believe there is a problem or can this report be closed? ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 08:00 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:59 Message: Logged In: YES user_id=1400763 My mistake. I had also called gc.get_objects() too. It was gc.get_objects() that outputed the content of the email message. It was not gc.garbage. Sorry about that. ---------------------------------------------------------------------- Comment By: ken668 (ken668) Date: 2005-12-12 07:53 Message: Logged In: YES user_id=1400763 I added these three lines after the line "msg=None" import gc print "gc.collect()\n\n", gc.collect() print "gc.garbage\n\n", gc.garbage If you pipe the output of gc.garbage to a file, you will see the email message you just sent are still be in the memory. Everytime I call email.message_from_string, a copy of the message will be kept in the memory even after I set the returned value to None. I tried the same thing with email package email-2.5.tar.gz, that memory was freed right after I set the variable "msg" to None. Thanks Ken ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 12:13 Message: Logged In: YES user_id=33168 What causes you to believe this is a memory leak? I ran this under valgrind and it doesn't report any leaks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470 From noreply at sourceforge.net Wed Dec 21 02:41:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 17:41:59 -0800 Subject: [ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError Message-ID: Bugs item #1386675, was opened at 2005-12-21 14:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 From noreply at sourceforge.net Wed Dec 21 06:28:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 21:28:13 -0800 Subject: [ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes Message-ID: Bugs item #1311784, was opened at 2005-10-03 05:18 Message generated for change (Comment added) made by khepri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Peter Klotz (pete_icoserve) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe 2.4.2 compiled with VS2005 crashes Initial Comment: The C runtime library shipped with Visual Studio 2005 performs strict checking of parameters. In function initsignal() in file Modules\signalmodule.c, an iteration over all signals from 1 to NSIG is performed. The function PyOS_getsig() is called with each of these integer values. PyOS_getsig() then calls signal() with the given value which leads to the crash. According to signal.h from VS2005 only these signals are allowed: #define SIGINT 2 #define SIGILL 4 #define SIGABRT_COMPAT 6 #define SIGFPE 8 #define SIGSEGV 11 #define SIGTERM 15 #define SIGBREAK 21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. ---------------------------------------------------------------------- Comment By: Kirjah Salys (khepri) Date: 2005-12-20 21:28 Message: Logged In: YES user_id=488858 VS2005 is out, and this bug still occurs in the release version (of both Python and VS2005). Is there any workaround for this? I can't see any being posted, and I replaced my system-wide compiler. It wouldn't exactly be feasible to accept the basic binary distribution or 'downgrade' my compiler in any event (Python has library binary compatibility problems in a wide variety of cases with external programs/libraries). Is Python's official stance to still pretend that VS2005 doesn't exist? And while it's probable that this violates standard (what compiler/library doesn't nowadays? *bleh*), and the 'deprecation warnings' get on nerves, this causes Python to crash "for no good reason" when compiled with it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-12 00:56 Message: Logged In: YES user_id=21627 Thanks for pointing out the earlier report, closing this one as a duplicate. Re: the platform SDK includes the same CRT: I somewhat doubt that statement. In my copy of the SDK, I have a msvcrt.dll version 6.10.2207.0, and the CRT sources don't have assertions in them. I can't ultimately test this, though, as I don't have the hardware. Re: it's an assertion. So does everybody agree that this is not conforming to ISO C? It should be worked-around in Python, sure, but preferably only after the release of the compiler, and preferably only after researching alternative solutions in the CRT sources of VS2005. ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-12 00:01 Message: Logged In: YES user_id=299547 Re: AMD64 compilers are available as part of the current platform SDK as available to MSDN subscribers (not through the free SDK download), and also reportedly available as part of the DDK. It is true that the current platform SDK supports AMD64 but the included compiler has version number 14.00 and comes with the same C runtime that is shipped with VS2005. I should have stated 'there is no AMD64 support prior to cl 14.00' rather than 'there is no AMD64 support prior to VS2005'. Nevertheless if you have to compile for AMD64 under Windows you have to use cl 14.00 and you cannot avoid the C runtime library showing the new signal behavior. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2005-10-11 17:17 Message: Logged In: YES user_id=1067739 This has been reported before. Maybe these two bugs should me merged somehow: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 The older bug report states that it's an assertion error, not a crash. That's consistent with the recent security clean-up of the CRT in VS 2005. I don't think that MS will fix this, since they are the ones which added the extra assertions. I've looked through the source code of the .NET 2003 version and it works as in ANSI-C (SIG_ERR is returned for unknown signals). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-11 16:36 Message: Logged In: YES user_id=21627 Re: this should be fixed: It certainly should (but doing so is less important than fixing problems which affect the actual distribution). Re: Conformance with ISO C. "implementation-defined" is not "undefined". Implementation-defined behaviour must be within the specified behaviour, chosing one of possible alternatives. The alternative to chose is the specific set of signals to support. For unsupported signals, the quoted text specifies: "If the request can be honored, the signal function returns the value of func for the most recent call to signal for the specified signal sig . Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno ." So if signal() would return SIG_ERR, this would be conformant. If execution would be aborted, this would not be conformant. Unfortunately, this report does not tell which of these it is: it only says "performs strict checking of parameters", without saying what the effect of this checking is. "leads to a the crash" suggests that there is a crash of some kind, though. Re: no AMD64 compiler prior to VS2005: this is not true. AMD64 compilers are available as part of the current platform SDK as available to MSDN subscribers (not through the free SDK download), and also reportedly available as part of the DDK. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2005-10-11 14:14 Message: Logged In: YES user_id=1067739 I'm not so sure that setting an unsupporting signal and expecting the operation to not crash/abort is valid ANSI-C: http://www.ndp77.net/ansi_c/ac04.htm#4.7 Quote: "The complete set of signals, their semantics, and their default handling is implementation-defined; all signal values shall be positive." Listed under "Implementation-Defined Behavior": http://msdn.microsoft.com/library/en-us/vclang/html/_CLANG_The_signal_Function.asp The list of supported signals: http://msdn.microsoft.com/library/en-us/vclib/html/_CRT_signal.asp I'll also switch to VS 2005 soon. This should be fixed, even if the binary distribution will continue to be compiled using VS .NET 2003. ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-11 06:10 Message: Logged In: YES user_id=299547 I think we misunderstand each other. My intention was not to force anyone to change his compiler. AFAIK there is no AMD64 support prior to VS2005 (i.e. compiler version 14.00). Therefore as soon as one has to compile for AMD64 he runs into the initial problem of this bug report. The only thing I am asking for is to incorporate a (hopefully small) VS2005 specific workaround in the source code of Python. The default compiler should remain VS2003 (i.e. compiler version 13.10). So no one has to change his compiler. However people that are forced to use VS2005 do not run into this specific problem anymore. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-10 13:13 Message: Logged In: YES user_id=21627 Yes, I really do. Users have protested a lot when we switched from VC6 to VS.NET2003, because they had to buy new compilers. We cannot reasonably force another compiler switch on them next year. However, this is off-topic for this bug report, please discuss it on python-dev. As for 64-bit windows support: I happily build 64-bit Windows binaries all the time with VS.NET2003, see www.python.org/2.4.2. There are no AMD64 binaries released, but extending the technology to support, say, the AMD64 SDK compiler would be possible. Patches to the actual code are greatfully accepted. ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-10 00:05 Message: Logged In: YES user_id=299547 Do you really think ignoring/skipping VS2005 is a proper solution? I am currently porting our software to 64Bit Windows (AMD64/EM64T) and the only compiler supporting this is the one included in VS2005. If Python does not support VS2005 everyone needing a 64Bit version of Python is forced to locate and fix this problem on his own. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-08 02:56 Message: Logged In: YES user_id=21627 Can somebody please study the source of the C runtime of VS2005 (probably needs to be requested specifically during installation), to find out whether more generic solutions are available. Possible solutions include: - don't call signal, but call an alternative function instead which won't cause a crash - set some magic variable, disabling the error checking - fetch the list of supported signals from somewhere (at compile time or at run time), and iterate over that list. Anyway, I don't see the official Python 2.5 release built with VS 2005, so this is a minor issue - I rather expect Python to skip VS 2005, and go right to the version that succeeds it. ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-04 01:02 Message: Logged In: YES user_id=299547 I would leave the code for pre-VS2005 compilers as is and introduce a specific workaround for VS2005 and all following compilers. Something like this comes to my mind: #if defined (_WIN32) && _MSC_VER >= 1400 ... #endif This works for 32 and 64 bit platforms since _WIN32 is defined in both cases. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 12:54 Message: Logged In: YES user_id=33168 Do you suggest this be special cased for VS2005 specifically or Windows in general (ie, any version/compiler)? ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-03 11:10 Message: Logged In: YES user_id=299547 VS2005 is still not released. It is scheduled for November 7th 2005. I tested with CTP (Community Technology Preview) August 2005. However I doubt they will change the behavior of their C library at this point of development. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-10-03 06:05 Message: Logged In: YES user_id=6656 Is VS2005 actually out now then? This behaviour violates the C standard, as far as we can tell, so we when VS2005 was in beta we hoped that they would fix it for the final release. If it is released, though, I guess we need to do something like you suggest (along with some colourful comments, I guess). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 From noreply at sourceforge.net Wed Dec 21 06:43:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 21:43:30 -0800 Subject: [ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes Message-ID: Bugs item #1311784, was opened at 2005-10-03 05:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Peter Klotz (pete_icoserve) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe 2.4.2 compiled with VS2005 crashes Initial Comment: The C runtime library shipped with Visual Studio 2005 performs strict checking of parameters. In function initsignal() in file Modules\signalmodule.c, an iteration over all signals from 1 to NSIG is performed. The function PyOS_getsig() is called with each of these integer values. PyOS_getsig() then calls signal() with the given value which leads to the crash. According to signal.h from VS2005 only these signals are allowed: #define SIGINT 2 #define SIGILL 4 #define SIGABRT_COMPAT 6 #define SIGFPE 8 #define SIGSEGV 11 #define SIGTERM 15 #define SIGBREAK 21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-20 21:43 Message: Logged In: YES user_id=33168 If you track down the references you will find the change has been made to the CM repository in revision 41554. See patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1350409&group_id=5470&atid=305470 The work around is to download the source and build python yourself, ensuring the patch is applied. How do you propose we backpatch already released versions? ---------------------------------------------------------------------- Comment By: Kirjah Salys (khepri) Date: 2005-12-20 21:28 Message: Logged In: YES user_id=488858 VS2005 is out, and this bug still occurs in the release version (of both Python and VS2005). Is there any workaround for this? I can't see any being posted, and I replaced my system-wide compiler. It wouldn't exactly be feasible to accept the basic binary distribution or 'downgrade' my compiler in any event (Python has library binary compatibility problems in a wide variety of cases with external programs/libraries). Is Python's official stance to still pretend that VS2005 doesn't exist? And while it's probable that this violates standard (what compiler/library doesn't nowadays? *bleh*), and the 'deprecation warnings' get on nerves, this causes Python to crash "for no good reason" when compiled with it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-12 00:56 Message: Logged In: YES user_id=21627 Thanks for pointing out the earlier report, closing this one as a duplicate. Re: the platform SDK includes the same CRT: I somewhat doubt that statement. In my copy of the SDK, I have a msvcrt.dll version 6.10.2207.0, and the CRT sources don't have assertions in them. I can't ultimately test this, though, as I don't have the hardware. Re: it's an assertion. So does everybody agree that this is not conforming to ISO C? It should be worked-around in Python, sure, but preferably only after the release of the compiler, and preferably only after researching alternative solutions in the CRT sources of VS2005. ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-12 00:01 Message: Logged In: YES user_id=299547 Re: AMD64 compilers are available as part of the current platform SDK as available to MSDN subscribers (not through the free SDK download), and also reportedly available as part of the DDK. It is true that the current platform SDK supports AMD64 but the included compiler has version number 14.00 and comes with the same C runtime that is shipped with VS2005. I should have stated 'there is no AMD64 support prior to cl 14.00' rather than 'there is no AMD64 support prior to VS2005'. Nevertheless if you have to compile for AMD64 under Windows you have to use cl 14.00 and you cannot avoid the C runtime library showing the new signal behavior. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2005-10-11 17:17 Message: Logged In: YES user_id=1067739 This has been reported before. Maybe these two bugs should me merged somehow: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 The older bug report states that it's an assertion error, not a crash. That's consistent with the recent security clean-up of the CRT in VS 2005. I don't think that MS will fix this, since they are the ones which added the extra assertions. I've looked through the source code of the .NET 2003 version and it works as in ANSI-C (SIG_ERR is returned for unknown signals). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-11 16:36 Message: Logged In: YES user_id=21627 Re: this should be fixed: It certainly should (but doing so is less important than fixing problems which affect the actual distribution). Re: Conformance with ISO C. "implementation-defined" is not "undefined". Implementation-defined behaviour must be within the specified behaviour, chosing one of possible alternatives. The alternative to chose is the specific set of signals to support. For unsupported signals, the quoted text specifies: "If the request can be honored, the signal function returns the value of func for the most recent call to signal for the specified signal sig . Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno ." So if signal() would return SIG_ERR, this would be conformant. If execution would be aborted, this would not be conformant. Unfortunately, this report does not tell which of these it is: it only says "performs strict checking of parameters", without saying what the effect of this checking is. "leads to a the crash" suggests that there is a crash of some kind, though. Re: no AMD64 compiler prior to VS2005: this is not true. AMD64 compilers are available as part of the current platform SDK as available to MSDN subscribers (not through the free SDK download), and also reportedly available as part of the DDK. ---------------------------------------------------------------------- Comment By: Adal Chiriliuc (adalx) Date: 2005-10-11 14:14 Message: Logged In: YES user_id=1067739 I'm not so sure that setting an unsupporting signal and expecting the operation to not crash/abort is valid ANSI-C: http://www.ndp77.net/ansi_c/ac04.htm#4.7 Quote: "The complete set of signals, their semantics, and their default handling is implementation-defined; all signal values shall be positive." Listed under "Implementation-Defined Behavior": http://msdn.microsoft.com/library/en-us/vclang/html/_CLANG_The_signal_Function.asp The list of supported signals: http://msdn.microsoft.com/library/en-us/vclib/html/_CRT_signal.asp I'll also switch to VS 2005 soon. This should be fixed, even if the binary distribution will continue to be compiled using VS .NET 2003. ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-11 06:10 Message: Logged In: YES user_id=299547 I think we misunderstand each other. My intention was not to force anyone to change his compiler. AFAIK there is no AMD64 support prior to VS2005 (i.e. compiler version 14.00). Therefore as soon as one has to compile for AMD64 he runs into the initial problem of this bug report. The only thing I am asking for is to incorporate a (hopefully small) VS2005 specific workaround in the source code of Python. The default compiler should remain VS2003 (i.e. compiler version 13.10). So no one has to change his compiler. However people that are forced to use VS2005 do not run into this specific problem anymore. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-10 13:13 Message: Logged In: YES user_id=21627 Yes, I really do. Users have protested a lot when we switched from VC6 to VS.NET2003, because they had to buy new compilers. We cannot reasonably force another compiler switch on them next year. However, this is off-topic for this bug report, please discuss it on python-dev. As for 64-bit windows support: I happily build 64-bit Windows binaries all the time with VS.NET2003, see www.python.org/2.4.2. There are no AMD64 binaries released, but extending the technology to support, say, the AMD64 SDK compiler would be possible. Patches to the actual code are greatfully accepted. ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-10 00:05 Message: Logged In: YES user_id=299547 Do you really think ignoring/skipping VS2005 is a proper solution? I am currently porting our software to 64Bit Windows (AMD64/EM64T) and the only compiler supporting this is the one included in VS2005. If Python does not support VS2005 everyone needing a 64Bit version of Python is forced to locate and fix this problem on his own. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-08 02:56 Message: Logged In: YES user_id=21627 Can somebody please study the source of the C runtime of VS2005 (probably needs to be requested specifically during installation), to find out whether more generic solutions are available. Possible solutions include: - don't call signal, but call an alternative function instead which won't cause a crash - set some magic variable, disabling the error checking - fetch the list of supported signals from somewhere (at compile time or at run time), and iterate over that list. Anyway, I don't see the official Python 2.5 release built with VS 2005, so this is a minor issue - I rather expect Python to skip VS 2005, and go right to the version that succeeds it. ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-04 01:02 Message: Logged In: YES user_id=299547 I would leave the code for pre-VS2005 compilers as is and introduce a specific workaround for VS2005 and all following compilers. Something like this comes to my mind: #if defined (_WIN32) && _MSC_VER >= 1400 ... #endif This works for 32 and 64 bit platforms since _WIN32 is defined in both cases. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 12:54 Message: Logged In: YES user_id=33168 Do you suggest this be special cased for VS2005 specifically or Windows in general (ie, any version/compiler)? ---------------------------------------------------------------------- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-03 11:10 Message: Logged In: YES user_id=299547 VS2005 is still not released. It is scheduled for November 7th 2005. I tested with CTP (Community Technology Preview) August 2005. However I doubt they will change the behavior of their C library at this point of development. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-10-03 06:05 Message: Logged In: YES user_id=6656 Is VS2005 actually out now then? This behaviour violates the C standard, as far as we can tell, so we when VS2005 was in beta we hoped that they would fix it for the final release. If it is released, though, I guess we need to do something like you suggest (along with some colourful comments, I guess). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 From noreply at sourceforge.net Wed Dec 21 06:53:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 21:53:34 -0800 Subject: [ python-Bugs-1385055 ] execfile anomaly with "from __future__ import division" Message-ID: Bugs item #1385055, was opened at 2005-12-19 02:15 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: execfile anomaly with "from __future__ import division" Initial Comment: If I have a file init.py with two lines: from __future__ import division print 3/4 and I do [harri at dell-harri tests]$ python Python 2.4 (#1, Feb 16 2005, 01:23:25) [GCC 3.4.3 (Mandrakelinux 10.0 3.4.3-2mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> execfile('init.py') 0.75 >>> 3/4 0 I would have expected the latter to return 0.75 as well. Due to this it seems impossible to provide init code that would initialize the interactive prompt to future division behaviour. The same applies to exec statement. I'm not sure if this is bug, or an unfortunate feature. The documention is not very clear on this issue. -Harri ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-20 21:53 Message: Logged In: YES user_id=33168 Closing per your request. I don't see any particularly good place in the doc to add a comment. I agree a comment about -Qnew wouldn't hurt. ---------------------------------------------------------------------- Comment By: Harri Pasanen (harripasanen) Date: 2005-12-19 02:42 Message: Logged In: YES user_id=77088 Looks like this is a duplicate of [ 567568 ] future division broken w/ PYTHONSTARTUP http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=567568 As I suspected, it is an unfortunate feature. Tim's explication provides the missing documentation. And I assume the exec statement provides its own anonymous module. Btw. where is the -Qnew documented? from __future__ division docs should carry a pointer to it. Here is another thread on the subject in the ipython mailing list: http://scipy.net/pipermail/ipython-user/2005-December/001183.html This can be closed. -Harri ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385055&group_id=5470 From noreply at sourceforge.net Wed Dec 21 21:23:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Dec 2005 12:23:44 -0800 Subject: [ python-Bugs-1387483 ] sys.path[0] when executed thru a symbolic link Message-ID: Bugs item #1387483, was opened at 2005-12-21 18: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=1387483&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Jack Jansen (jackjansen) Summary: sys.path[0] when executed thru a symbolic link Initial Comment: Under certain conditions there is a difference between Mac OS X and Linux (both 2.4.1) with regard to the value of the variable sys.path[0] which should contain the directory from which the script was called. This difference appears when the script is called through a symbolic link by a different user. See the attached example. It should be executed once by the owner of the TESTPATH directory: ~/TESTPATH/sub1/testpath.py and ~/TESTPATH/sub2/testpath.py In both cases, under Linux and Mac OS X, the result is: /home/owner/TESTPATH/sub1 If a different user executes: ~owner/TESTPATH/sub1/testpath.py and ~owner/TESTPATH/sub2/testpath.py he gets the same results under Linux: /home/owner/TESTPATH/sub1 but two different results under Mac OS: /Users/owner/TESTPATH/sub1 and /Users/owner/TESTPATH/sub2 This seems like a minor problem but it breaks my application because sys.path[0] is the first place to look for imports! I am not sure whether this is a Python problem or something to do with the Mac OS X. My Mac OS X version is 10.4.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&group_id=5470 From noreply at sourceforge.net Wed Dec 21 21:39:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Dec 2005 12:39:05 -0800 Subject: [ python-Bugs-1387483 ] sys.path[0] when executed thru a symbolic link Message-ID: Bugs item #1387483, was opened at 2005-12-21 21:23 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Jack Jansen (jackjansen) Summary: sys.path[0] when executed thru a symbolic link Initial Comment: Under certain conditions there is a difference between Mac OS X and Linux (both 2.4.1) with regard to the value of the variable sys.path[0] which should contain the directory from which the script was called. This difference appears when the script is called through a symbolic link by a different user. See the attached example. It should be executed once by the owner of the TESTPATH directory: ~/TESTPATH/sub1/testpath.py and ~/TESTPATH/sub2/testpath.py In both cases, under Linux and Mac OS X, the result is: /home/owner/TESTPATH/sub1 If a different user executes: ~owner/TESTPATH/sub1/testpath.py and ~owner/TESTPATH/sub2/testpath.py he gets the same results under Linux: /home/owner/TESTPATH/sub1 but two different results under Mac OS: /Users/owner/TESTPATH/sub1 and /Users/owner/TESTPATH/sub2 This seems like a minor problem but it breaks my application because sys.path[0] is the first place to look for imports! I am not sure whether this is a Python problem or something to do with the Mac OS X. My Mac OS X version is 10.4.3. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-12-21 21:39 Message: Logged In: YES user_id=45365 I don't see this problem: both users see "sub1" as the working directory. Also on 10.4.3. My guess: there is some problem with the readlink() call that Python uses to obtain the real pathname of the script (this is how it finds out sub2/ testpath.py is really sub1/testpath.py. Easy to test: fire up Python as user 2 and do os.readlink("/Users/owner/TESTPATH/sub2"). I wouldn't be surprised if it is some sort of permission problem (maybe / Users/owner being mode rwx--x--x so the readlink can't traverse through it?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&group_id=5470 From noreply at sourceforge.net Thu Dec 22 01:04:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Dec 2005 16:04:15 -0800 Subject: [ python-Bugs-1387650 ] weird behavior when assigning locals() to a variable Message-ID: Bugs item #1387650, was opened at 2005-12-22 00:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: weird behavior when assigning locals() to a variable Initial Comment: Tried this on Python 2.3.3, under Redhat Linux Enterprise 3, and on Python 2.3.5, under MacOS X 10.4.3. Don't have access to 2.4 anywhere, so I can't test it, but I took a look at the bug queue and can't find any reference to this problem. The following function yields a KeyError when run: def foo(): b = locals() c = 5 print b["c"] The following function does not: def foo(): b = locals() c = 5 locals() print b["c"] There's no typo there. After referencing locals() again, without updating the value of b, the printout works. Note that b and locals(), as I believe is intended, are identical: def foo(): b = locals() c = 5 print id(b) print b.has_key() print id(locals()) print b.has_key() yields, when run: >>> foo() 285984 False 285984 True This has GOT to be a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 From noreply at sourceforge.net Thu Dec 22 01:25:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Dec 2005 16:25:05 -0800 Subject: [ python-Bugs-1387650 ] weird behavior when assigning locals() to a variable Message-ID: Bugs item #1387650, was opened at 2005-12-22 00:04 Message generated for change (Comment added) made by sambayer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: weird behavior when assigning locals() to a variable Initial Comment: Tried this on Python 2.3.3, under Redhat Linux Enterprise 3, and on Python 2.3.5, under MacOS X 10.4.3. Don't have access to 2.4 anywhere, so I can't test it, but I took a look at the bug queue and can't find any reference to this problem. The following function yields a KeyError when run: def foo(): b = locals() c = 5 print b["c"] The following function does not: def foo(): b = locals() c = 5 locals() print b["c"] There's no typo there. After referencing locals() again, without updating the value of b, the printout works. Note that b and locals(), as I believe is intended, are identical: def foo(): b = locals() c = 5 print id(b) print b.has_key() print id(locals()) print b.has_key() yields, when run: >>> foo() 285984 False 285984 True This has GOT to be a bug. ---------------------------------------------------------------------- >Comment By: Samuel Bayer (sambayer) Date: 2005-12-22 00:25 Message: Logged In: YES user_id=40146 OK, it doesn't got to be a bug. After staring at the documentation for locals(), I realize that locals() is only updated when it's called again. So it's not a bug, but it is a little odd. It's the only namespace-like object you can't reliably use as a format string argument. Consider the following: >>> b = globals() >>> c = 5 >>> print "%(c)d" % b This prints the expected value. Ditto this: >>> Class Foo: pass >>> a = Foo(); b = a.__dict__ >>> a.c = 5 >>> print "%(c)d" % b Only with locals(), inside a function, does this pattern fail. I imagine it would be expensive to make work, though. Never mind... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 From noreply at sourceforge.net Thu Dec 22 06:48:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Dec 2005 21:48:53 -0800 Subject: [ python-Bugs-1387650 ] weird behavior when assigning locals() to a variable Message-ID: Bugs item #1387650, was opened at 2005-12-21 16:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: weird behavior when assigning locals() to a variable Initial Comment: Tried this on Python 2.3.3, under Redhat Linux Enterprise 3, and on Python 2.3.5, under MacOS X 10.4.3. Don't have access to 2.4 anywhere, so I can't test it, but I took a look at the bug queue and can't find any reference to this problem. The following function yields a KeyError when run: def foo(): b = locals() c = 5 print b["c"] The following function does not: def foo(): b = locals() c = 5 locals() print b["c"] There's no typo there. After referencing locals() again, without updating the value of b, the printout works. Note that b and locals(), as I believe is intended, are identical: def foo(): b = locals() c = 5 print id(b) print b.has_key() print id(locals()) print b.has_key() yields, when run: >>> foo() 285984 False 285984 True This has GOT to be a bug. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-21 21:48 Message: Logged In: YES user_id=33168 If you have suggestions for how we can improve the doc, let us know. I'll close this bug report since you seem to agree it's not a bug. ---------------------------------------------------------------------- Comment By: Samuel Bayer (sambayer) Date: 2005-12-21 16:25 Message: Logged In: YES user_id=40146 OK, it doesn't got to be a bug. After staring at the documentation for locals(), I realize that locals() is only updated when it's called again. So it's not a bug, but it is a little odd. It's the only namespace-like object you can't reliably use as a format string argument. Consider the following: >>> b = globals() >>> c = 5 >>> print "%(c)d" % b This prints the expected value. Ditto this: >>> Class Foo: pass >>> a = Foo(); b = a.__dict__ >>> a.c = 5 >>> print "%(c)d" % b Only with locals(), inside a function, does this pattern fail. I imagine it would be expensive to make work, though. Never mind... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 From noreply at sourceforge.net Thu Dec 22 06:52:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Dec 2005 21:52:27 -0800 Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *= Message-ID: Bugs item #1355842, was opened at 2005-11-13 03:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) >Assigned to: Facundo Batista (facundobatista) Summary: Incorrect Decimal-float behavior for += and *= Initial Comment: The += and *= operators have strange behavior when the LHS is a Decimal and the RHS is a float (as of 2005-11-13 CVS decimal.py). Example: >>> d = Decimal('1.02') >>> d += 2.1 >>> d NotImplemented A blatant violation of "Errors should never pass silently." Also, a bad error description is produced for the *= operator: >>> d = Decimal('1.02') >>> d *= 2.9 Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-21 21:52 Message: Logged In: YES user_id=33168 Facundo, can you look into this? Are you still working on Decimal? ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-12-01 22:17 Message: Logged In: YES user_id=1039782 The += and *= operations also give the same strange behavior when the LHS is a Decimal and the RHS is str or unicode: >>> d = Decimal("1.0") >>> d += "5" >>> d NotImplemented >>> d = Decimal("1.0") >>> d *= "1.0" Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 20:43 Message: Logged In: YES user_id=33168 Hmmm. __add__ returns NotImplemented which works with classic classes, but not new-style classes. I wonder if NotImplementedError is supposed to be raised for new-style classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 From noreply at sourceforge.net Thu Dec 22 12:40:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 03:40:51 -0800 Subject: [ python-Bugs-1387483 ] sys.path[0] when executed thru a symbolic link Message-ID: Bugs item #1387483, was opened at 2005-12-21 18:23 Message generated for change (Comment added) made by kowaltowski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Jack Jansen (jackjansen) Summary: sys.path[0] when executed thru a symbolic link Initial Comment: Under certain conditions there is a difference between Mac OS X and Linux (both 2.4.1) with regard to the value of the variable sys.path[0] which should contain the directory from which the script was called. This difference appears when the script is called through a symbolic link by a different user. See the attached example. It should be executed once by the owner of the TESTPATH directory: ~/TESTPATH/sub1/testpath.py and ~/TESTPATH/sub2/testpath.py In both cases, under Linux and Mac OS X, the result is: /home/owner/TESTPATH/sub1 If a different user executes: ~owner/TESTPATH/sub1/testpath.py and ~owner/TESTPATH/sub2/testpath.py he gets the same results under Linux: /home/owner/TESTPATH/sub1 but two different results under Mac OS: /Users/owner/TESTPATH/sub1 and /Users/owner/TESTPATH/sub2 This seems like a minor problem but it breaks my application because sys.path[0] is the first place to look for imports! I am not sure whether this is a Python problem or something to do with the Mac OS X. My Mac OS X version is 10.4.3. ---------------------------------------------------------------------- >Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2005-12-22 09:40 Message: Logged In: YES user_id=185428 (1) I think it is a problem because under Mac OS X the user #2 sees "sub2" (and not "sub1"!) as the working directory, which is where it is different from Linux. (2) The problem persists even if all permissions are open. (3) The implementation of "os.readlink" migh be the right clue about the problem: when the user #2 executes "os.readlink("/Users/owner/TESTPATH/sub2/testpath.py") the answer under Mac OS X is: OSError: [Errorno 13] Permission denied: '/Users/owner/TESTPATH/sub2/testpath.py' even though all permissions are open. Under Linux I get the expected answer: "../sub1/testpath.py". Obviously there is a problem under Mac OS X, and this matter should be reopen. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-12-21 18:39 Message: Logged In: YES user_id=45365 I don't see this problem: both users see "sub1" as the working directory. Also on 10.4.3. My guess: there is some problem with the readlink() call that Python uses to obtain the real pathname of the script (this is how it finds out sub2/ testpath.py is really sub1/testpath.py. Easy to test: fire up Python as user 2 and do os.readlink("/Users/owner/TESTPATH/sub2"). I wouldn't be surprised if it is some sort of permission problem (maybe / Users/owner being mode rwx--x--x so the readlink can't traverse through it?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&group_id=5470 From noreply at sourceforge.net Thu Dec 22 14:24:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 05:24:57 -0800 Subject: [ python-Bugs-1387650 ] weird behavior when assigning locals() to a variable Message-ID: Bugs item #1387650, was opened at 2005-12-22 00:04 Message generated for change (Comment added) made by sambayer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: weird behavior when assigning locals() to a variable Initial Comment: Tried this on Python 2.3.3, under Redhat Linux Enterprise 3, and on Python 2.3.5, under MacOS X 10.4.3. Don't have access to 2.4 anywhere, so I can't test it, but I took a look at the bug queue and can't find any reference to this problem. The following function yields a KeyError when run: def foo(): b = locals() c = 5 print b["c"] The following function does not: def foo(): b = locals() c = 5 locals() print b["c"] There's no typo there. After referencing locals() again, without updating the value of b, the printout works. Note that b and locals(), as I believe is intended, are identical: def foo(): b = locals() c = 5 print id(b) print b.has_key() print id(locals()) print b.has_key() yields, when run: >>> foo() 285984 False 285984 True This has GOT to be a bug. ---------------------------------------------------------------------- >Comment By: Samuel Bayer (sambayer) Date: 2005-12-22 13:24 Message: Logged In: YES user_id=40146 This morning, as I thought about it some more, I had some vain hope that the __getitem__ method of that particular dictionary could be updated to refresh the dictionary, but after trolling through the source a little, I see that it's really just a regular dictionary, and it doesn't know anything about where it came from. Would it be dangerous to add the current stack frame to the locals() dictionary as a value like __frame___? Perhaps that would screw up the garbage collection by adding a circular reference. In any case, the current documentation for locals() reads: "Update and return a dictionary representing the current local symbol table. Warning: The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter." I'd say something like "Update and return a dictionary representing the current local symbol table. Warnings: The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter. Also, this dictionary is not guaranteed to be synchronized with the actual local environment; if the local symbol table changes between the time you retrieve the value of locals() and the time you use it, you won't see the changes." ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-22 05:48 Message: Logged In: YES user_id=33168 If you have suggestions for how we can improve the doc, let us know. I'll close this bug report since you seem to agree it's not a bug. ---------------------------------------------------------------------- Comment By: Samuel Bayer (sambayer) Date: 2005-12-22 00:25 Message: Logged In: YES user_id=40146 OK, it doesn't got to be a bug. After staring at the documentation for locals(), I realize that locals() is only updated when it's called again. So it's not a bug, but it is a little odd. It's the only namespace-like object you can't reliably use as a format string argument. Consider the following: >>> b = globals() >>> c = 5 >>> print "%(c)d" % b This prints the expected value. Ditto this: >>> Class Foo: pass >>> a = Foo(); b = a.__dict__ >>> a.c = 5 >>> print "%(c)d" % b Only with locals(), inside a function, does this pattern fail. I imagine it would be expensive to make work, though. Never mind... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 From noreply at sourceforge.net Thu Dec 22 16:56:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 07:56:17 -0800 Subject: [ python-Bugs-1388141 ] Minor error in md5 docs Message-ID: Bugs item #1388141, was opened at 2005-12-22 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=1388141&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Minor error in md5 docs Initial Comment: In the Library Reference 15.2 md5 section, the new() and md5() functions are introduced with the text "md5 objects support the following methods:". These are module-level functions, not instance methods, so a better text would be "The md5 module provides the following functions:" Thanks, Kent ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388141&group_id=5470 From noreply at sourceforge.net Thu Dec 22 17:15:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 08:15:24 -0800 Subject: [ python-Bugs-1388141 ] Minor error in md5 docs Message-ID: Bugs item #1388141, was opened at 2005-12-22 16:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388141&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Minor error in md5 docs Initial Comment: In the Library Reference 15.2 md5 section, the new() and md5() functions are introduced with the text "md5 objects support the following methods:". These are module-level functions, not instance methods, so a better text would be "The md5 module provides the following functions:" Thanks, Kent ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-22 17:15 Message: Logged In: YES user_id=1188172 Thanks, corrected in rev. 41787/41788. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388141&group_id=5470 From noreply at sourceforge.net Thu Dec 22 18:10:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 09:10:53 -0800 Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *= Message-ID: Bugs item #1355842, was opened at 2005-11-13 08:17 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Facundo Batista (facundobatista) Summary: Incorrect Decimal-float behavior for += and *= Initial Comment: The += and *= operators have strange behavior when the LHS is a Decimal and the RHS is a float (as of 2005-11-13 CVS decimal.py). Example: >>> d = Decimal('1.02') >>> d += 2.1 >>> d NotImplemented A blatant violation of "Errors should never pass silently." Also, a bad error description is produced for the *= operator: >>> d = Decimal('1.02') >>> d *= 2.9 Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-12-22 14:10 Message: Logged In: YES user_id=752496 Regarding problem 1: Nick also detected this behaviour, back in March (http://mail.python.org/pipermail/python-dev/2005-March/051834.html), in python-dev discussions about how integrate better the Decimal behaviour into Python framework. Even knowing this, Raymond Hettinger and I made a patch (almost exactly the same), and corrected another behaviour. Will this issue be resolved somewhen? Raymond said that this problem is also present in sets.py and datetime objects (http://mail.python.org/pipermail/python-dev/2005-March/051825.html), and that should be addressed in a larger context than decimal. As Neil Schemenauer proposed (http://mail.python.org/pipermail/python-dev/2005-March/051829.html), Decimal now returns NotImplemented instead of raise TypeError, which should be the correct way to deal with operation capabilities in the numbers. And look at this: >>> d Decimal("1") # using decimal.py rev. 39328 from svn >>> d + 1.2 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'Decimal' and 'float' >>> d += 1.2 >>> d NotImplemented >>> Why this happens? Really don't know, it's beyond my actual knowledge, I'll keep searching. But I'm not so sure that this is a Decimal issue. Regarding problem 2: I'll fix that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-22 02:52 Message: Logged In: YES user_id=33168 Facundo, can you look into this? Are you still working on Decimal? ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-12-02 03:17 Message: Logged In: YES user_id=1039782 The += and *= operations also give the same strange behavior when the LHS is a Decimal and the RHS is str or unicode: >>> d = Decimal("1.0") >>> d += "5" >>> d NotImplemented >>> d = Decimal("1.0") >>> d *= "1.0" Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 01:43 Message: Logged In: YES user_id=33168 Hmmm. __add__ returns NotImplemented which works with classic classes, but not new-style classes. I wonder if NotImplementedError is supposed to be raised for new-style classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 From noreply at sourceforge.net Thu Dec 22 22:31:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 13:31:37 -0800 Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *= Message-ID: Bugs item #1355842, was opened at 2005-11-13 12:17 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Facundo Batista (facundobatista) Summary: Incorrect Decimal-float behavior for += and *= Initial Comment: The += and *= operators have strange behavior when the LHS is a Decimal and the RHS is a float (as of 2005-11-13 CVS decimal.py). Example: >>> d = Decimal('1.02') >>> d += 2.1 >>> d NotImplemented A blatant violation of "Errors should never pass silently." Also, a bad error description is produced for the *= operator: >>> d = Decimal('1.02') >>> d *= 2.9 Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-22 22:31 Message: Logged In: YES user_id=38388 Hi Facundo, the problem you are seeing seems to be in the way new-style classes implement number coercion. Apparently some part in the (not so new-style anymore) coercion logic is masking an exception which then triggers later during processing. The NotImplemented singleton should never make it to the interactive shell since it is normally only used internally by the number coercion logic to signal "object method doesn't handle mixed type operation". ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-12-22 18:10 Message: Logged In: YES user_id=752496 Regarding problem 1: Nick also detected this behaviour, back in March (http://mail.python.org/pipermail/python-dev/2005-March/051834.html), in python-dev discussions about how integrate better the Decimal behaviour into Python framework. Even knowing this, Raymond Hettinger and I made a patch (almost exactly the same), and corrected another behaviour. Will this issue be resolved somewhen? Raymond said that this problem is also present in sets.py and datetime objects (http://mail.python.org/pipermail/python-dev/2005-March/051825.html), and that should be addressed in a larger context than decimal. As Neil Schemenauer proposed (http://mail.python.org/pipermail/python-dev/2005-March/051829.html), Decimal now returns NotImplemented instead of raise TypeError, which should be the correct way to deal with operation capabilities in the numbers. And look at this: >>> d Decimal("1") # using decimal.py rev. 39328 from svn >>> d + 1.2 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'Decimal' and 'float' >>> d += 1.2 >>> d NotImplemented >>> Why this happens? Really don't know, it's beyond my actual knowledge, I'll keep searching. But I'm not so sure that this is a Decimal issue. Regarding problem 2: I'll fix that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-22 06:52 Message: Logged In: YES user_id=33168 Facundo, can you look into this? Are you still working on Decimal? ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-12-02 07:17 Message: Logged In: YES user_id=1039782 The += and *= operations also give the same strange behavior when the LHS is a Decimal and the RHS is str or unicode: >>> d = Decimal("1.0") >>> d += "5" >>> d NotImplemented >>> d = Decimal("1.0") >>> d *= "1.0" Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 05:43 Message: Logged In: YES user_id=33168 Hmmm. __add__ returns NotImplemented which works with classic classes, but not new-style classes. I wonder if NotImplementedError is supposed to be raised for new-style classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 From noreply at sourceforge.net Fri Dec 23 01:43:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 16:43:40 -0800 Subject: [ python-Bugs-1388489 ] bug in rstrip & lstrip Message-ID: Bugs item #1388489, was opened at 2005-12-23 00:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jason Whitlark (jcdelta) Assigned to: Nobody/Anonymous (nobody) Summary: bug in rstrip & lstrip Initial Comment: quick detail: Python 2.4.2 (#1, Dec 9 2005, 22:48:42) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "net.tpl".rstrip('.tpl') 'ne' >>> "foo.tpl".rstrip('.tpl') 'foo' I ran the following code to test this: 26 - [jwhitlark at Snowflake]: ~/pythonBugTest 0> cat testForRStripBug.py #! /usr/bin/python for word in open('/opt/openoffice/share/dict/ooo/en_US.dic', 'r'): word = word.split('/')[0] testWord = (word + '.tpl').rstrip('.tpl') if word != testWord: print word, testWord And came up with the attached file of incorrect matches. Out of 62075 words in the en_US.dic, 6864 do not match. Here is the frequency count of the last letter of the origional word, the only pattern I could discern so far: 0> ./freqCount.py < run1 {'p': 566, 'l': 2437, 't': 3861} No other letters seem to be clipped. Why this should be so, I have no idea. I would guess that the error was in function do_xstrip in python/trunk/Objects/stringobject.c, but C is not my strong suit. I will be looking at it further when I have time, but if anyone knows how to fix this, please help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&group_id=5470 From noreply at sourceforge.net Fri Dec 23 02:23:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 17:23:25 -0800 Subject: [ python-Bugs-1388489 ] bug in rstrip & lstrip Message-ID: Bugs item #1388489, was opened at 2005-12-23 01:43 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jason Whitlark (jcdelta) Assigned to: Nobody/Anonymous (nobody) Summary: bug in rstrip & lstrip Initial Comment: quick detail: Python 2.4.2 (#1, Dec 9 2005, 22:48:42) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "net.tpl".rstrip('.tpl') 'ne' >>> "foo.tpl".rstrip('.tpl') 'foo' I ran the following code to test this: 26 - [jwhitlark at Snowflake]: ~/pythonBugTest 0> cat testForRStripBug.py #! /usr/bin/python for word in open('/opt/openoffice/share/dict/ooo/en_US.dic', 'r'): word = word.split('/')[0] testWord = (word + '.tpl').rstrip('.tpl') if word != testWord: print word, testWord And came up with the attached file of incorrect matches. Out of 62075 words in the en_US.dic, 6864 do not match. Here is the frequency count of the last letter of the origional word, the only pattern I could discern so far: 0> ./freqCount.py < run1 {'p': 566, 'l': 2437, 't': 3861} No other letters seem to be clipped. Why this should be so, I have no idea. I would guess that the error was in function do_xstrip in python/trunk/Objects/stringobject.c, but C is not my strong suit. I will be looking at it further when I have time, but if anyone knows how to fix this, please help. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-12-23 02:23 Message: Logged In: YES user_id=89016 This is not a bug. The documentation (http://docs.python.org/lib/string-methods.html) says that: "The chars argument is a string specifying the set of characters to be removed". i.e. "net.tpl".rstrip(".tpl") strips every ".", "t", "p" and "l" character from the right end of the string, *not* every occurence of the character sequence ".tpl". This seems to be a frequent misunderstanding, so if you can suggest improvements to the docstring or the documentation, please do so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&group_id=5470 From noreply at sourceforge.net Fri Dec 23 09:49:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 00:49:30 -0800 Subject: [ python-Bugs-1388489 ] bug in rstrip & lstrip Message-ID: Bugs item #1388489, was opened at 2005-12-23 01:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jason Whitlark (jcdelta) Assigned to: Nobody/Anonymous (nobody) Summary: bug in rstrip & lstrip Initial Comment: quick detail: Python 2.4.2 (#1, Dec 9 2005, 22:48:42) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "net.tpl".rstrip('.tpl') 'ne' >>> "foo.tpl".rstrip('.tpl') 'foo' I ran the following code to test this: 26 - [jwhitlark at Snowflake]: ~/pythonBugTest 0> cat testForRStripBug.py #! /usr/bin/python for word in open('/opt/openoffice/share/dict/ooo/en_US.dic', 'r'): word = word.split('/')[0] testWord = (word + '.tpl').rstrip('.tpl') if word != testWord: print word, testWord And came up with the attached file of incorrect matches. Out of 62075 words in the en_US.dic, 6864 do not match. Here is the frequency count of the last letter of the origional word, the only pattern I could discern so far: 0> ./freqCount.py < run1 {'p': 566, 'l': 2437, 't': 3861} No other letters seem to be clipped. Why this should be so, I have no idea. I would guess that the error was in function do_xstrip in python/trunk/Objects/stringobject.c, but C is not my strong suit. I will be looking at it further when I have time, but if anyone knows how to fix this, please help. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-23 09:49 Message: Logged In: YES user_id=1188172 The docs clearly state this behavior. """ >>> 'www.example.com'.lstrip('cmowz.') 'example.com' """ ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-23 02:23 Message: Logged In: YES user_id=89016 This is not a bug. The documentation (http://docs.python.org/lib/string-methods.html) says that: "The chars argument is a string specifying the set of characters to be removed". i.e. "net.tpl".rstrip(".tpl") strips every ".", "t", "p" and "l" character from the right end of the string, *not* every occurence of the character sequence ".tpl". This seems to be a frequent misunderstanding, so if you can suggest improvements to the docstring or the documentation, please do so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&group_id=5470 From noreply at sourceforge.net Fri Dec 23 12:26:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 03:26:54 -0800 Subject: [ python-Bugs-1388804 ] Polymorphic getters / setters Message-ID: Bugs item #1388804, was opened at 2005-12-23 12:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388804&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Adde (trialcode) Assigned to: Nobody/Anonymous (nobody) Summary: Polymorphic getters / setters Initial Comment: If you add a property to a class with a getter and/or setter and override the getter and/or setter in a subclass the baseclass implementation of the methods is still called when the property is accessed on objects of the subclass. class base(object): def get_foo(self): print "Base get" def set_foo(self, value): print "Base set" foo = property(get_foo, set_foo) class sub(base): def get_foo(self): print "Sub get" def set_foo(self, value): print "Sub set" s = sub() s.foo = s.foo -- Prints: Base get Base set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388804&group_id=5470 From noreply at sourceforge.net Fri Dec 23 12:32:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 03:32:52 -0800 Subject: [ python-Bugs-1388804 ] Polymorphic getters / setters Message-ID: Bugs item #1388804, was opened at 2005-12-23 12:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388804&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Adde (trialcode) Assigned to: Nobody/Anonymous (nobody) Summary: Polymorphic getters / setters Initial Comment: If you add a property to a class with a getter and/or setter and override the getter and/or setter in a subclass the baseclass implementation of the methods is still called when the property is accessed on objects of the subclass. class base(object): def get_foo(self): print "Base get" def set_foo(self, value): print "Base set" foo = property(get_foo, set_foo) class sub(base): def get_foo(self): print "Sub get" def set_foo(self, value): print "Sub set" s = sub() s.foo = s.foo -- Prints: Base get Base set ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-23 12:32 Message: Logged In: YES user_id=1188172 This is expected behavior. The property is created with references to the specific methods "base.get_foo" and "base.set_foo". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388804&group_id=5470 From noreply at sourceforge.net Fri Dec 23 14:08:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 05:08:36 -0800 Subject: [ python-Feature Requests-1388872 ] Polymorphic getters / setters Message-ID: Feature Requests item #1388872, was opened at 2005-12-23 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=355470&aid=1388872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adde (trialcode) Assigned to: Nobody/Anonymous (nobody) Summary: Polymorphic getters / setters Initial Comment: If you add a property to a class with a getter and/or setter and override the getter and/or setter in a subclass the baseclass implementation of the methods is still called when the property is accessed on objects of the subclass (see below for example). This feels like a pretty arbitrary limitation that prevents overriding the behaviour of properties like you would with a normal method. I'm sure there's a way to make the property search the inheritance-hierarchy for the provided method signature when called. class base(object): def get_foo(self): print "Base get" def set_foo(self, value): print "Base set" foo = property(get_foo, set_foo) class sub(base): def get_foo(self): print "Sub get" def set_foo(self, value): print "Sub set" s = sub() s.foo = s.foo -- Prints: Base get Base set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1388872&group_id=5470 From noreply at sourceforge.net Fri Dec 23 15:02:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 06:02:54 -0800 Subject: [ python-Bugs-1388910 ] xmlrpc howto link incorrect Message-ID: Bugs item #1388910, was opened at 2005-12-23 14: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=1388910&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Marshall (jonmarsh) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpc howto link incorrect Initial Comment: Clicking the link for the xml-rpc HOWTO in the xml-rpc module documentation results in an error 404. This is true for both the 2.3 and 2.4 documentation on pages http://www.python.org/doc/2.3.5/lib/module-xmlrpclib.html and http://docs.python.org/lib/module-xmlrpclib.html The target page is http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html. Perhaps it should be http://tldp.org/HOWTO/XML-RPC-HOWTO/index.html ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388910&group_id=5470 From noreply at sourceforge.net Fri Dec 23 16:11:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 07:11:26 -0800 Subject: [ python-Bugs-1388949 ] Decimal sqrt() ignores rounding Message-ID: Bugs item #1388949, was opened at 2005-12-23 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=1388949&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal sqrt() ignores rounding Initial Comment: Decimal Contexts' sqrt() method exhibits the same rounding behavior irregardless of the rounding parameter. >>> c = decimal.Context(rounding=decimal.ROUND_CEILING) >>> f = decimal.Context(rounding=decimal.ROUND_FLOOR) >>> cs = decimal.Context(rounding=decimal.ROUND_CEILING, prec=14) >>> fs = decimal.Context(rounding=decimal.ROUND_FLOOR, prec=14) >>> c.sqrt(D(2)) Decimal("1.414213562373095048801688724") >>> f.sqrt(D(2)) Decimal("1.414213562373095048801688724") >>> cs.sqrt(D(2)) Decimal("1.4142135623731") >>> fs.sqrt(D(2)) Decimal("1.4142135623731") It appears to always round up. Python 2.4.2 (#2, Nov 20 2005, 17:04:48) Debian unstable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388949&group_id=5470 From noreply at sourceforge.net Fri Dec 23 19:03:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 10:03:56 -0800 Subject: [ python-Bugs-1388910 ] xmlrpc howto link incorrect Message-ID: Bugs item #1388910, was opened at 2005-12-23 15:02 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388910&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jonathan Marshall (jonmarsh) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpc howto link incorrect Initial Comment: Clicking the link for the xml-rpc HOWTO in the xml-rpc module documentation results in an error 404. This is true for both the 2.3 and 2.4 documentation on pages http://www.python.org/doc/2.3.5/lib/module-xmlrpclib.html and http://docs.python.org/lib/module-xmlrpclib.html The target page is http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html. Perhaps it should be http://tldp.org/HOWTO/XML-RPC-HOWTO/index.html ? ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-23 19:03 Message: Logged In: YES user_id=38376 This is a duplicate of http://www.python.org/sf/1368827 (which is already fixed in the trunk) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388910&group_id=5470 From noreply at sourceforge.net Fri Dec 23 19:11:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 10:11:10 -0800 Subject: [ python-Bugs-1389051 ] imaplib causes excessive fragmentation for large documents Message-ID: Bugs item #1389051, was opened at 2005-12-23 19: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=1389051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib causes excessive fragmentation for large documents Initial Comment: When fetching large documents via SSL, the imaplib attempts to read it all in one chunk, but the SSL socket layer only returns ~16k at a time. The result is that Python will end up allocating, say, a 15 megabyte block, shrink it to a few kilobytes, occasionally allocate a medium-sized block (to hold the list of chunks), and repeat this again and again and again. Not all malloc implementations can reuse the (15 megabytes minus a few kilobyte) block when allocating the next 15 megabyte block. In a worst case scenario, you'll need some 13 gigabytes of virtual memory to read a 15 megabyte message... A simple solution is to change data = self.sslobj.read(size-read) to data = self.sslobj.read(min(size-read, 16384)) For more on this, see this thread: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/3737500bac287575/d715bf614a86e786 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389051&group_id=5470 From noreply at sourceforge.net Fri Dec 23 22:29:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 13:29:17 -0800 Subject: [ python-Bugs-1389157 ] test_tarfile fails with readonly source dir for Python 2.4.2 Message-ID: Bugs item #1389157, was opened at 2005-12-23 22: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=1389157&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Langly (langly) Assigned to: Nobody/Anonymous (nobody) Summary: test_tarfile fails with readonly source dir for Python 2.4.2 Initial Comment: When compiling Python-2.4.2 and using separate source and build directories, the test_tarfile test fails if the source directory is read-only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389157&group_id=5470 From noreply at sourceforge.net Sat Dec 24 18:13:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Dec 2005 09:13:04 -0800 Subject: [ python-Bugs-1388949 ] Decimal sqrt() ignores rounding Message-ID: Bugs item #1388949, was opened at 2005-12-23 12:11 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388949&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam Olsen (rhamphoryncus) >Assigned to: Facundo Batista (facundobatista) Summary: Decimal sqrt() ignores rounding Initial Comment: Decimal Contexts' sqrt() method exhibits the same rounding behavior irregardless of the rounding parameter. >>> c = decimal.Context(rounding=decimal.ROUND_CEILING) >>> f = decimal.Context(rounding=decimal.ROUND_FLOOR) >>> cs = decimal.Context(rounding=decimal.ROUND_CEILING, prec=14) >>> fs = decimal.Context(rounding=decimal.ROUND_FLOOR, prec=14) >>> c.sqrt(D(2)) Decimal("1.414213562373095048801688724") >>> f.sqrt(D(2)) Decimal("1.414213562373095048801688724") >>> cs.sqrt(D(2)) Decimal("1.4142135623731") >>> fs.sqrt(D(2)) Decimal("1.4142135623731") It appears to always round up. Python 2.4.2 (#2, Nov 20 2005, 17:04:48) Debian unstable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388949&group_id=5470 From noreply at sourceforge.net Sat Dec 24 18:46:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Dec 2005 09:46:12 -0800 Subject: [ python-Bugs-1388949 ] Decimal sqrt() ignores rounding Message-ID: Bugs item #1388949, was opened at 2005-12-23 12:11 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388949&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Facundo Batista (facundobatista) Summary: Decimal sqrt() ignores rounding Initial Comment: Decimal Contexts' sqrt() method exhibits the same rounding behavior irregardless of the rounding parameter. >>> c = decimal.Context(rounding=decimal.ROUND_CEILING) >>> f = decimal.Context(rounding=decimal.ROUND_FLOOR) >>> cs = decimal.Context(rounding=decimal.ROUND_CEILING, prec=14) >>> fs = decimal.Context(rounding=decimal.ROUND_FLOOR, prec=14) >>> c.sqrt(D(2)) Decimal("1.414213562373095048801688724") >>> f.sqrt(D(2)) Decimal("1.414213562373095048801688724") >>> cs.sqrt(D(2)) Decimal("1.4142135623731") >>> fs.sqrt(D(2)) Decimal("1.4142135623731") It appears to always round up. Python 2.4.2 (#2, Nov 20 2005, 17:04:48) Debian unstable ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-12-24 14:46 Message: Logged In: YES user_id=752496 The rounding setting in the context is not used, always uses the round-half-even algorithm, as specified in the Decimal Specification (see http://www2.hursley.ibm.com/decimal/daops.html#refsqrt). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388949&group_id=5470 From noreply at sourceforge.net Sat Dec 24 19:27:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Dec 2005 10:27:06 -0800 Subject: [ python-Bugs-1389673 ] Incorrectly docs for return values of set update methods Message-ID: Bugs item #1389673, was opened at 2005-12-24 13: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=1389673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrectly docs for return values of set update methods Initial Comment: The documentation for set.update(), set.intersection_update(), set.difference_update() and set.symmetric_difference_update currently (as of r41806) states that these methods all return the updated set, implying that this is a not-in-place change. In fact, these methods do operate in place, each one of them returning None. The attached diff (against Doc/lib/libstdtypes.tex, r41806) fixes this, making it clear that these are in-place operations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389673&group_id=5470 From noreply at sourceforge.net Sat Dec 24 19:27:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Dec 2005 10:27:35 -0800 Subject: [ python-Bugs-1389673 ] Incorrect docs for return values of set update methods Message-ID: Bugs item #1389673, was opened at 2005-12-24 13:27 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect docs for return values of set update methods Initial Comment: The documentation for set.update(), set.intersection_update(), set.difference_update() and set.symmetric_difference_update currently (as of r41806) states that these methods all return the updated set, implying that this is a not-in-place change. In fact, these methods do operate in place, each one of them returning None. The attached diff (against Doc/lib/libstdtypes.tex, r41806) fixes this, making it clear that these are in-place operations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389673&group_id=5470 From noreply at sourceforge.net Sun Dec 25 00:35:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Dec 2005 15:35:50 -0800 Subject: [ python-Bugs-1389809 ] Fxn call in _elementtree.c has incorrect signedness Message-ID: Bugs item #1389809, was opened at 2005-12-24 15: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=1389809&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Fredrik Lundh (effbot) Summary: Fxn call in _elementtree.c has incorrect signedness Initial Comment: Line 2149 in Modules/_elementtree.c calls PyUnicode_Decode() with an array of ``unsigned char`` while the definition of the function in Objects/unicodeobject.c has the argument as ``const char *``. Here is the relevant output from the build: /Users/drifty/Code/Trees/svn/python/trunk/Modules/_elementtree.c: In function 'expat_unknown_encoding_handler': /Users/drifty/Code/Trees/svn/python/trunk/Modules/_elementtree.c:2149: warning: pointer targets in passing argument 1 of 'PyUnicodeUCS2_Decode' differ in signedness ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389809&group_id=5470 From noreply at sourceforge.net Sun Dec 25 11:57:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Dec 2005 02:57:08 -0800 Subject: [ python-Bugs-1389051 ] imaplib causes excessive fragmentation for large documents Message-ID: Bugs item #1389051, was opened at 2005-12-23 19:11 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib causes excessive fragmentation for large documents Initial Comment: When fetching large documents via SSL, the imaplib attempts to read it all in one chunk, but the SSL socket layer only returns ~16k at a time. The result is that Python will end up allocating, say, a 15 megabyte block, shrink it to a few kilobytes, occasionally allocate a medium-sized block (to hold the list of chunks), and repeat this again and again and again. Not all malloc implementations can reuse the (15 megabytes minus a few kilobyte) block when allocating the next 15 megabyte block. In a worst case scenario, you'll need some 13 gigabytes of virtual memory to read a 15 megabyte message... A simple solution is to change data = self.sslobj.read(size-read) to data = self.sslobj.read(min(size-read, 16384)) For more on this, see this thread: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/3737500bac287575/d715bf614a86e786 ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 11:57 Message: Logged In: YES user_id=38376 As noted in that thread, the same problem applies to non- SSL accesses. The problematic line is: data = self._sock.recv(recv_size) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389051&group_id=5470 From noreply at sourceforge.net Sun Dec 25 12:41:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Dec 2005 03:41:48 -0800 Subject: [ python-Bugs-1389809 ] Fxn call in _elementtree.c has incorrect signedness Message-ID: Bugs item #1389809, was opened at 2005-12-25 00:35 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389809&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Fredrik Lundh (effbot) Summary: Fxn call in _elementtree.c has incorrect signedness Initial Comment: Line 2149 in Modules/_elementtree.c calls PyUnicode_Decode() with an array of ``unsigned char`` while the definition of the function in Objects/unicodeobject.c has the argument as ``const char *``. Here is the relevant output from the build: /Users/drifty/Code/Trees/svn/python/trunk/Modules/_elementtree.c: In function 'expat_unknown_encoding_handler': /Users/drifty/Code/Trees/svn/python/trunk/Modules/_elementtree.c:2149: warning: pointer targets in passing argument 1 of 'PyUnicodeUCS2_Decode' differ in signedness ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389809&group_id=5470 From noreply at sourceforge.net Sun Dec 25 12:44:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Dec 2005 03:44:46 -0800 Subject: [ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError Message-ID: Bugs item #1386675, was opened at 2005-12-21 02:41 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 12:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 From noreply at sourceforge.net Sun Dec 25 16:06:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Dec 2005 07:06:12 -0800 Subject: [ python-Bugs-1390086 ] ScrolledText hungs up in some conditions Message-ID: Bugs item #1390086, was opened at 2005-12-25 18: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=1390086&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: dani_filth (dani_filth) Assigned to: Nobody/Anonymous (nobody) Summary: ScrolledText hungs up in some conditions Initial Comment: The next code causes Python to hung in some conditions : #------------------------------------------------------ from ScrolledText import * root=Tk() ScrolledText(root, bg='white').pack(fill=BOTH, expand=YES) root.mainloop() #------------------------------------------------------ Run the script. Pass focus to the text field. Then enter one Tab and type several letters. After that with having pushed Ctrl-key press several times UP button. Script hungs with 100% CPU-usage. P.S. My config : WinXP sp2, python 2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390086&group_id=5470 From noreply at sourceforge.net Sun Dec 25 21:41:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Dec 2005 12:41:19 -0800 Subject: [ python-Feature Requests-1390197 ] tempfile misses usecase which requirs renaming Message-ID: Feature Requests item #1390197, was opened at 2005-12-25 20:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1390197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dennis Allison (dallison) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile misses usecase which requirs renaming Initial Comment: tempfile provides a very convenient API but it seems to miss one important use case. For example, suppose the program is stream editing the file. Typically one reads the source file, edits the data, and writes it to a temporary file. Upon successful completion of the edit, the program renames the temporary to be the original source file, which is atomic in most operating systems, There does not appear to be any neat way to do this with the current API without the program throwing an exception because of the deletion wrapper. Perhaps a "rename" method needs to be added to manage the delete seamlessly. I am not especially fond of that solution as it adds new functionality to file descriptors. . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1390197&group_id=5470 From noreply at sourceforge.net Mon Dec 26 03:36:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Dec 2005 18:36:04 -0800 Subject: [ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError Message-ID: Bugs item #1386675, was opened at 2005-12-21 14:41 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). ---------------------------------------------------------------------- >Comment By: Tony Meyer (anadelonbrin) Date: 2005-12-26 15:36 Message: Logged In: YES user_id=552329 I don't see what purpose there is in having the documentation say that EnvironmentError is raised, when a subclass is. _winreg is still marked as a temporary module to be replaced, so it's hard to believe it's some sort of future-proofing. One could say that Exception is raised, since EnvironmentError is a subclass of Exception, but explicit is better than implicit, right? (import _winreg fails on non-Windows platforms, so I don't see how it could be for cross-platform reasons, either). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-26 00:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 From noreply at sourceforge.net Mon Dec 26 05:11:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Dec 2005 20:11:52 -0800 Subject: [ python-Bugs-1390321 ] README mention --without-cxx Message-ID: Bugs item #1390321, was opened at 2005-12-25 20: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=1390321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: README mention --without-cxx Initial Comment: This just verified against HEAD: ./configure fails on Linux without g++ installed unless --without-cxx given. README should mention this. Error is checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables Inside config.log it says: gcc: installation problem, cannot exec 'cc1plus': No such file or directory (There's been some discussion about not requiring C++ installation by default -- until that's settled, we should at least update the README.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&group_id=5470 From noreply at sourceforge.net Mon Dec 26 15:58:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 06:58:02 -0800 Subject: [ python-Bugs-1390605 ] time docs lack %F in strftime! Message-ID: Bugs item #1390605, was opened at 2005-12-26 16: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=1390605&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: time docs lack %F in strftime! Initial Comment: time.strftime('%F', t) '2005-12-26' but docs hide it they may hide more ;( :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390605&group_id=5470 From noreply at sourceforge.net Mon Dec 26 16:03:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 07:03:58 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-26 17: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=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: Nobody/Anonymous (nobody) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Mon Dec 26 16:28:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 07:28:41 -0800 Subject: [ python-Bugs-1390629 ] time.strftime('%F', local_time) is okay but time.strptime no Message-ID: Bugs item #1390629, was opened at 2005-12-26 17:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390629&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: time.strftime('%F', local_time) is okay but time.strptime no Initial Comment: THIS IS SUPER HUGE IMO >>> a = time.strftime('%F', local_time) >>> time.strptime(a, '%F') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 287, in strptime format_regex = time_re.compile(format) File "/usr/lib/python2.4/_strptime.py", line 264, in compile return re_compile(self.pattern(format), IGNORECASE) File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: 'F' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390629&group_id=5470 From noreply at sourceforge.net Mon Dec 26 17:31:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 08:31:03 -0800 Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *= Message-ID: Bugs item #1355842, was opened at 2005-11-13 11:17 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Facundo Batista (facundobatista) Summary: Incorrect Decimal-float behavior for += and *= Initial Comment: The += and *= operators have strange behavior when the LHS is a Decimal and the RHS is a float (as of 2005-11-13 CVS decimal.py). Example: >>> d = Decimal('1.02') >>> d += 2.1 >>> d NotImplemented A blatant violation of "Errors should never pass silently." Also, a bad error description is produced for the *= operator: >>> d = Decimal('1.02') >>> d *= 2.9 Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-26 16:31 Message: Logged In: YES user_id=4771 See proposed patch: #1390657 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-22 21:31 Message: Logged In: YES user_id=38388 Hi Facundo, the problem you are seeing seems to be in the way new-style classes implement number coercion. Apparently some part in the (not so new-style anymore) coercion logic is masking an exception which then triggers later during processing. The NotImplemented singleton should never make it to the interactive shell since it is normally only used internally by the number coercion logic to signal "object method doesn't handle mixed type operation". ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-12-22 17:10 Message: Logged In: YES user_id=752496 Regarding problem 1: Nick also detected this behaviour, back in March (http://mail.python.org/pipermail/python-dev/2005-March/051834.html), in python-dev discussions about how integrate better the Decimal behaviour into Python framework. Even knowing this, Raymond Hettinger and I made a patch (almost exactly the same), and corrected another behaviour. Will this issue be resolved somewhen? Raymond said that this problem is also present in sets.py and datetime objects (http://mail.python.org/pipermail/python-dev/2005-March/051825.html), and that should be addressed in a larger context than decimal. As Neil Schemenauer proposed (http://mail.python.org/pipermail/python-dev/2005-March/051829.html), Decimal now returns NotImplemented instead of raise TypeError, which should be the correct way to deal with operation capabilities in the numbers. And look at this: >>> d Decimal("1") # using decimal.py rev. 39328 from svn >>> d + 1.2 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'Decimal' and 'float' >>> d += 1.2 >>> d NotImplemented >>> Why this happens? Really don't know, it's beyond my actual knowledge, I'll keep searching. But I'm not so sure that this is a Decimal issue. Regarding problem 2: I'll fix that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-22 05:52 Message: Logged In: YES user_id=33168 Facundo, can you look into this? Are you still working on Decimal? ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2005-12-02 06:17 Message: Logged In: YES user_id=1039782 The += and *= operations also give the same strange behavior when the LHS is a Decimal and the RHS is str or unicode: >>> d = Decimal("1.0") >>> d += "5" >>> d NotImplemented >>> d = Decimal("1.0") >>> d *= "1.0" Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 04:43 Message: Logged In: YES user_id=33168 Hmmm. __add__ returns NotImplemented which works with classic classes, but not new-style classes. I wonder if NotImplementedError is supposed to be raised for new-style classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 From noreply at sourceforge.net Mon Dec 26 18:13:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 09:13:03 -0800 Subject: [ python-Bugs-729913 ] metaclasses, __getattr__, and special methods Message-ID: Bugs item #729913, was opened at 2003-04-29 23:57 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Nobody/Anonymous (nobody) Summary: metaclasses, __getattr__, and special methods Initial Comment: __getattr__ on metaclasses aren't called when it would seem "logical" <wink> for it to be. E.g.: >>> class meta(type): ... def __getattr__(cls, name): ... if name == '__len__': ... print "meta.__getattr__('__len__')" ... return lambda: 42 ... else: ... print 'meta.__getattr__', name ... return name ... >>> class S(object): ... __metaclass__ = meta ... >>> S.__len__() meta.__getattr__('__len__') 42 >>> len(S) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: len() of unsized object >>> I was told that special method "foo(x, arg)" was implemented as "type(x).__foo__(x, arg)", which doesn't seem to be the case always... Compare: >>> class meta(type): ... def __len__(cls): ... return 42 ... >>> class S(object): ... __metaclass__ = meta ... >>> S.__len__() 42 >>> len(S) 42 >>> So, it looks like it's looking up __len__ in the metaclass, but not falling back on __getattr__ when it isn't there? I've looked at the C code and it seems like special methods each have their own way of finding the function they're needing. >From Alex Martelli: Ah yes, I see now! Yes, functions such as len() rely on slots in the type object, e.g. as you've noticed: > finding the function they're needing, e.g. for len, it looks like it > uses: > > m = o->ob_type->tp_as_sequence; > if (m && m->sq_length) > return m->sq_length(o); > > return PyMapping_Size(o); and the "incredibly complex thinking" (quoting from typeobject.c) in update_one_slot doesn't seem to work except for operations the which "the class overrides in its dict" (again from a comment in typeobject.c, this one for fixup_slot_dispatchers). The issue may be with _PyType_Lookup (again in the same ,c file), which just gives up if it can't find a name somewhere along the mro (it doesn't "look upwards" to the metaclass) while type_getattro DOES work upwards on the metaclass too. Hmmmm. I'm not sure I really understand all that's going on here - it IS a rather hairy zone of the code. Maybe you can post this as a bug in 2.3 beta 1 on sourgeforge (ideally showing where in the docs it defines the semantics that it then doesn't respect) so we can get this looked at by the few people who really DO grasp these parts...;- ). There is probably some sound implementation reason for the current behavior, but if so it should be better documented, I think. Back to me: The point being that I haven't found any place in the documentation that defines what the attribute lookup is on new-style classes (and the C code is too hairy for me to understand :-) As a special case of this problem, super() can't create an object which intercepts the special methods like it does for other methods, e.g.: super(MyCls, self).__getitem__(5) works, but not super(MyCls, self)[5] I don't know if that is intended or not, but it's not documented, though neither is exactly _what_ super is? (i.e. it looks like it's an object, that when you call a method, 'm', on it, uses the superclass method 'm', but the subclass versions of all other methods, although as above, not in all contexts, and I'm not sure whether you're supposed to be able to treat it as a first class object [pass as arg, return, etc]).... -- bjorn ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-26 17:13 Message: Logged In: YES user_id=4771 This is a known documentation bug: all this is expected, but under-documented. Indeed, len(x) calls the special method __len__ of 'x', but what is not specified is the real definition of "calling a special method" on an object 'x': it is to look up the name "__len__" in the dict of type(x), then in the dict of the parent types in MRO order. It's really not the same thing as an attribute lookup. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-01 13:43 Message: Logged In: YES user_id=1188172 I closed #789262 as a duplicate of this one. More info may be there. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-15 07:20 Message: Logged In: YES user_id=6656 You could try http://starship.python.net/crew/mwh/hacks/oop-after-python22.txt (or attach pdf to the end instead...) You say: > The point being that I haven't found any place in the > documentation that defines what the attribute lookup is > on new-style classes That's not the problem -- attribute lookup is fairly easy. What you're missing is that attribute lookup != special method lookup. This probably should be in the core documentation, yes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729913&group_id=5470 From noreply at sourceforge.net Mon Dec 26 18:21:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 09:21:41 -0800 Subject: [ python-Bugs-1066490 ] special methods become static Message-ID: Bugs item #1066490, was opened at 2004-11-15 06:46 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066490&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.3 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Michael Hudson (mwh) Summary: special methods become static Initial Comment: This *may* be a duplicate of 729913, but there's either additional info here, or this is actually different. The issue is that any special method (e.g. __call__, __str__, etc.) defined for a new-style (i.e. object-based) class seems to be static (i.e. unchangeable) with some special lookup applied for that method, but this doesn't seem to be the case for regular methods. class A: def foo(self): return 1 def __call__(self): return 2 def bar(self): return 3 def adjust(self): self.foo = self.bar self.__call__ = self.bar a = A() print a.foo(), a() a.adjust() print a.foo(), a() Will print: 1 2 3 3 But if the A is turned into a new-style class by changing the first line: class A(object): then the printed results are: 1 2 3 2 To the best of my understanding of the migration from classic classes to new-style classes (and metaclassing), this shouldn't occur. I have also tried various name munging for the special method (e.g. setting _B__call__, using setattr, etc.), but I haven't found the special trick yet. The attached script shows the example in more detail. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-26 17:21 Message: Logged In: YES user_id=4771 Re-closing. This is a known documentation bug: all this is expected, but just under-documented. 'str(x)' issues a special method call to '__str__' on 'x', but the real definition of "calling a special method" on an object 'x' is as follows: look up the name "__str__" in the dict of type(x), then in the dict of the parent types in MRO order. It's really not the same thing as an attribute lookup. The reason for this, to put Michael's argument differently, is that if 'str(x)' would really work like 'x.__str__()', then this is what would occur: >>> class X(object): ... def __repr__(self): ... return "hello" ... >>> X() hello >>> X TypeError: __repr__() takes exactly 1 argument (0 given) because X.__repr__() is just an unbound method call with a missing argument. There is no such thing as "default values for self" in Python. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 20:55 Message: Logged In: YES user_id=1188172 It is not the case that the methods are unchangeable. See this example: class A(object): def __repr__(self): return 'repr' def new_repr(self): return 'new_repr' a = A() a.__repr__ = a.new_repr print a.__repr__() => prints "new_repr" print repr(a) => prints "repr" ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2004-12-22 19:00 Message: Logged In: YES user_id=6133 Thanks for the clarifcation. However IMHO it is wrong to have different behavior for different methods. To wit, if I defined a method, it is a bound method, and ergo a "self" initial argument is automatically supplied. However, a __repr__, even though I define it, acts as an unbound method, with the self argument having a default of the current instance but overrideable if an argument is supplied on the call. This means that the argument evaluation/passing is different for these types of builtins as opposed to other methods, both of which I have defined myself. This just doesn't seem right to me, which is why I'm re-opening this bug report... sorry to be annoying, but this definitely seems inconsistent and a better explanation. My current workaround is to do the following: class foo: def __str__(self): return my_str() def my_str(self): return 'something' So that I can do "foo.my_str = lambda self: return 'something else'". When what I should be able to do is: class foo: def __str__(self): return 'something' ... foo.__str__ = lambda self: return 'something else' ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-16 08:22 Message: Logged In: YES user_id=6656 Oh, sorry, I think I got that a bit wrong. The issue is more with bound/unbound methods -- given class O(object): def __repr__(self): ... should O.__repr__ be a bound method (O is an instance of type) or an unbound method so O.__repr__(O()) does what you expect? Python chooses the latter, but this means that you can't implement the builtin function repr as def repr(o): return o.__repr__() Hope this helps, a little at least. ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2004-11-15 14:29 Message: Logged In: YES user_id=6133 OK, I didn't find anything documenting this change anywhere (obviously). I read Guido's description of new-classes (www.python.org/2.2/descrintro.py) and the various documentation, but either I overlooked it therein or it's talked about somewhere else. I'm curious as to why special methods are treated specially in regards to this lookup. Specifically for your example, why wouldn't you just use the __repr__ attribute of o if it exists, instead of o's class, just like it does for non-special methods? Can you briefly explain this or provide me with a reference? Leaving this closed is OK with me since it's apparently known and expected... I'd just like to understand it a bit better. Sorry for the bandwidth, and Thanks! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-15 07:16 Message: Logged In: YES user_id=6656 The change you are observing is that special methods are now only looked up on the *class* of the object concerned. This, or something like this is actually unavoidable -- in >>> repr(o) what do you do if both o and the type of o define a __repr__ method? There are articles on new-style classes out there that should explain this in more depth. It probably could/should be documented better in the core -- there are bugs open to that effect already. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066490&group_id=5470 From noreply at sourceforge.net Mon Dec 26 18:27:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 09:27:24 -0800 Subject: [ python-Bugs-1382740 ] len() on class broken Message-ID: Bugs item #1382740, was opened at 2005-12-16 20:18 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) >Assigned to: Nobody/Anonymous (nobody) Summary: len() on class broken Initial Comment: With the following python input: class A: @classmethod def __len__(cls): return 12 print '1',A.__len__() print '2',A().__len__() print '3',len(A()) print '4',len(A) The output always breaks for '4' with 'TypeError: len of unsized object' Same result for @staticmethod or normal instance method declaration. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-26 17:27 Message: Logged In: YES user_id=4771 Un-assigning Guido. This is a known documentation bug: all this is expected, but under-documented. Indeed, len(x) calls the special method __len__ of 'x', but that's quite different from the expression "x.__len__()". Indeed, the real definition of "calling a special method" on an object 'x' is to look up the name "__len__" in the dict of type(x), then in the dict of the parent types in MRO order. It's really not the same thing as an attribute lookup. This definition makes sense for the Python language; it has nothing to do with the C slots. The reason is more fundamental. Consider, say, what would occur if "repr(x)" was equivalent to "x.__repr__()": >>> class X(object): ... def __repr__(self): ... return "hello" ... >>> X() hello >>> X TypeError: __repr__() takes exactly 1 argument (0 given) because X.__repr__() is just an unbound method call with a missing argument. ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2005-12-19 15:25 Message: Logged In: YES user_id=6133 This bug *may* be related to Bug#1066490 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-17 04:40 Message: Logged In: YES user_id=80475 Guido, this issue arises throughout the language in various guises (for instance, it applies to __neg__ as well as __len__). It comes-up whenever built-in functions or operators bypass attribute lookup in favor of direct slot access. Much of the code in abstract.c is in the form: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) raise TypeError If we cared about this (and I'm not sure we do), the solution is to make the abstract.c functions smarter: def PyObject_SomeFunc(o): if slots.somefunc is not None: return slots.somefunc(o) try: f = gettattr(o, 'somefunc') except AttributeError: raise TypeError else: return f() The advantage of the change is restoring the symmetry between len(o) and o.__len__() where the method definition is available via attribute lookup but not via a slot. The thought is to keep the speedy access as default, but if that fails, then do a normal attribute lookup before barfing back an error message. This is precedent for this solution elsewhere in the codebase (though I don't remember where at the moment). OTOH, I'm not sure we care. pervades the code in abstract.c which is in the form: def PyObject_Size ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2005-12-16 22:52 Message: Logged In: YES user_id=6133 That would indeed solve '4', but has a non-orthogonality of attribute propagation that I don't understand and which seems inconsistent. In my original: '1' demonstrates that __len__ is indeed in the dictionary for the class. '2' shows the expected attribute propagation effects: if at attribute is not found in the instance dictionary, the class dictionary is checked. '3' shows that len is implemented (generally) by looking for a __len__ method on the object in question. '4' confuses me, because it means that '3' isn't quite correct... With your metaclass solution (using "__metaclass__ = meta" :) it does indeed make '4' work, and '1', but '2' and '3' now do not work, showing that instance-->class propagation does not follow instance-->class-->metaclass. Or something ... Approaching this a different way: My understanding of @classmethod (or perhaps more properly @staticmethod) is that it allows "constant" methods that are independent of the particular object instance. So if I had: class C: @staticmethod def f(): return 1 then both C.f() and C().f() are valid and return 1. Why the len() translation to __len__ works *differently* is strange. I'm still defining a method, just one that I want Python to use for any len(A) or len(A()) refs, translating those to A.__len__() or A().__len__() and using those just as for C and f, respectively. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 21:43 Message: Logged In: YES user_id=1188172 You want to use a metaclass: class meta(type): def __len__(cls): return 12 class B: __metaclass__ = B print len(B) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&group_id=5470 From noreply at sourceforge.net Mon Dec 26 19:01:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 10:01:37 -0800 Subject: [ python-Bugs-1390605 ] time docs lack %F in strftime! Message-ID: Bugs item #1390605, was opened at 2005-12-26 15:58 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390605&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: time docs lack %F in strftime! Initial Comment: time.strftime('%F', t) '2005-12-26' but docs hide it they may hide more ;( :( ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-26 19:01 Message: Logged In: YES user_id=1188172 strftime uses the platform's C library, which happens to support %F on your box. As the docs explicitly tell you: "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390605&group_id=5470 From noreply at sourceforge.net Mon Dec 26 19:02:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 10:02:21 -0800 Subject: [ python-Bugs-1390629 ] time.strftime('%F', local_time) is okay but time.strptime no Message-ID: Bugs item #1390629, was opened at 2005-12-26 16:28 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390629&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: time.strftime('%F', local_time) is okay but time.strptime no Initial Comment: THIS IS SUPER HUGE IMO >>> a = time.strftime('%F', local_time) >>> time.strptime(a, '%F') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 287, in strptime format_regex = time_re.compile(format) File "/usr/lib/python2.4/_strptime.py", line 264, in compile return re_compile(self.pattern(format), IGNORECASE) File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: 'F' ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-26 19:02 Message: Logged In: YES user_id=1188172 Closing as Invalid, see bug #1390605. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390629&group_id=5470 From noreply at sourceforge.net Mon Dec 26 23:41:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 14:41:21 -0800 Subject: [ python-Bugs-1102649 ] pickle files should be opened in binary mode Message-ID: Bugs item #1102649, was opened at 2005-01-14 22:58 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: pickle files should be opened in binary mode Initial Comment: pickle (and cPickle): At _each_ mention of the pickle file, the docs should say that it should be opened with 'wb' or 'rb' mode as appropriate, so that a pickle written on one OS can be read reliably on another. The example code at the end of the section should be updated to use the 'b' flag. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 21:08 Message: Logged In: YES user_id=21627 sjmachin, it seems pretty clear what to do now. Would you volunteer to come up with a patch yourself? ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-01-19 14:51 Message: Logged In: YES user_id=480138 Re Fred's question: Refer to thread starting at http://mail.python.org/pipermail/python-dev/2003- February/033362.html Looks like the story is like this: For pickle mode 1 or higher, always use binary mode for reading/writing. For pickle mode 0, either (a) read/write in text mode and if moving to another OS, do so in text mode i.e. convert the line endings where necessary or (b) as for pickle mode 1+, stick with binary throughout. Also should add a generalisation of Tim's comment re NotePad, e.g. something like """A file written with pickle mode 0 and file mode 'wb' will contain lone linefeeds as line terminators. This will cause it to "look funny" when viewed on Windows or MacOS as a text file by editors like Notepad that do not understand this format.""" ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 14:45 Message: Logged In: YES user_id=31435 Yes, binary mode should always be used, regardless of protocol. Else pickles aren't portable across boxes (in particular, Unix can't read a protocol 0 pickle produced on Windows if the latter was written to a text-mode file). "text mode" was a horrible name for protocol 0. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 06:09 Message: Logged In: YES user_id=3066 In response to irmin's comment: freopen() is only an option for real file objects; pickles are often stored or read from other sources. These other sources are usually binary to begin with, fortunately, though this issue probably deserves some real coverage in the documentation either way. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 06:06 Message: Logged In: YES user_id=3066 Is this true in all cases? Shouldn't files containing text pickles (protocol 0) be opened in text mode? (A problem, given that all protocols should be readable without prior knowledge of the protocol used to write the pickle.) ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:07 Message: Logged In: YES user_id=129426 Can't the pickle code just freopen() the file itself, using binary mode? Or is this against Python's rule "explicit is better than implicit" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 From noreply at sourceforge.net Mon Dec 26 23:54:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 14:54:17 -0800 Subject: [ python-Bugs-649974 ] urllib.url2pathname, pathname2url doc strings inconsistent Message-ID: Bugs item #649974, was opened at 2002-12-07 10:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.url2pathname, pathname2url doc strings inconsistent Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-26 23:54 Message: Logged In: YES user_id=1188172 Applied patches in revisions 41816,41817. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-28 06:18 Message: Logged In: YES user_id=371366 OK. I changed the group to Python 2.4, changed the category to Documentation, changed the summary, and lowered the priority. Since there are doc strings for the non-posix versions of url2pathname() and pathname2url(), please just consider the patches I created to be just making all of the docs consistent among each other and consistent with the module-level docs you pointed out. Thanks! -Mike ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-28 01:32 Message: Logged In: YES user_id=752496 The documentation for urllib states that: Although the urllib module contains (undocumented) routines to parse and unparse URL strings, the recommended interface for URL manipulation is in module urlparse. So, if you think that the files should also be modified, change the group of this bug to 2.4. Otherwise it will be closed as won't fix. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 08:15 Message: Logged In: YES user_id=371366 See also #649961, where I propose the same solution. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 08:04 Message: Logged In: YES user_id=371366 pathname2url and url2pathname are undocumented and are urllib- and platform-specific. My complaints in this old bug report are based on assumptions that thse functions are general-purpose public interfaces. Upon further investigation, I see that they are not. I suggest leaving the implementations unchanged for now; there are too many issues with doing it 'right' to go into here. But perhaps add documentation that is consistent and indicates that the functions are limited in scope. Patches attached. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 15:52 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 15:52 Message: Logged In: YES user_id=752496 Could you please provide a test case? ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-11 07:56 Message: Logged In: YES user_id=250749 There is a sort of convention in Unix - somehost:/path/to/file which comes from NFS, but has been used by tar (for remote tapes via rsh) and ssh's scp, and I believe has been used by some ftp clients (ncftp?) However as far as I know you can't pass such a path to open () or os.access(), so your basic point still has validity. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-12-07 10:24 Message: Logged In: YES user_id=371366 by 'host embedded in the URL' in the first sentence I meant 'host embedded in it' [the path] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply at sourceforge.net Mon Dec 26 23:59:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 14:59:37 -0800 Subject: [ python-Bugs-653542 ] PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Message-ID: Bugs item #653542, was opened at 2002-12-14 02:02 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Initial Comment: These two functions have mutually-recursive definitions in the docs (which is to say, none). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-26 23:59 Message: Logged In: YES user_id=1188172 I think the definitions are pretty clear to understand. PyLong_FromVoidPtr makes a long from a pointer, PyLong_AsVoidPtr makes a pointer from a long... closing as Works for Me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-24 03:25 Message: Logged In: YES user_id=31435 Nope. Guido checked them in 5 years ago, in rev 1.48. To judge from the checkin comment, the code may actually have come from Greg Stein. I don't have time for it, so unassigning. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-24 00:00 Message: Logged In: YES user_id=3066 Tim, aren't these your babies? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-14 17:15 Message: Logged In: YES user_id=21627 Something very simple: PyObject * PyLong_FromVoidPtr(void *p) { #if SIZEOF_VOID_P <= SIZEOF_LONG return PyInt_FromLong((long)p); #else #ifndef HAVE_LONG_LONG # error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long" #endif #if SIZEOF_LONG_LONG < SIZEOF_VOID_P # error "PyLong_FromVoidPtr: sizeof(LONG_LONG) < sizeof (void*)" #endif /* optimize null pointers */ if (p == NULL) return PyInt_FromLong(0); return PyLong_FromLongLong((LONG_LONG)p); #endif /* SIZEOF_VOID_P <= SIZEOF_LONG */ } ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-12-14 15:37 Message: Logged In: YES user_id=52572 Thanks for asking but the problem is that I don't know what they do! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-14 15:15 Message: Logged In: YES user_id=21627 Would you like to provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:01:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:01:26 -0800 Subject: [ python-Bugs-721160 ] Acrobat Reader 5 compatibility Message-ID: Bugs item #721160, was opened at 2003-04-14 17:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Acrobat Reader 5 compatibility Initial Comment: I read the comment about Adobe admitting that it can't print the Python documentation is their fault, but as the bug doesn't seem to get fixed, is there any workaround that we could make? Especially on MacOSX you have the problem that there is no Acrobat 4 that you can use (unless you want to run it under Classic), and it seems a bit silly to have all this beautiful documentation that people then can't print... ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:01 Message: Logged In: YES user_id=1188172 This has been lying around for more than two years, and the Reader is at version 7 now... I believe that I can close this as "Out of Date". ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-14 17:44 Message: Logged In: YES user_id=11105 I have been in contact with two other people about this bug, here is an extract from some conversation we had. I'll be happy to mail Fred his email adress, don't want to post it here on the web. > * From all I read, it seems that Fred Drake is convinced the problem > is an Acrobat bug, while you seem to have a good case it's actually > a problem in python.sty. At this point, contacting the Python guys Well, there is a bug in Acrobat Reader, but recent pdftex versions have a workaround for it. It might be that this is a different problem. > is appropriate - it would be great if you want to help here. Yes, I'll do this next week. > * About \url: actually I was suprized to see that urls don't work > as a link from my Acrobat (though I think I have a weblink set up > properly) - can that be related to the issue you describe? It seems python.sty defines its own \url command which apparently used to create hyperlinks, but as it was tailored to very specific pdftex (and hyperref) versions, it breaks now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=721160&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:08:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:08:22 -0800 Subject: [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks Message-ID: Bugs item #756104, was opened at 2003-06-17 20:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alex R.M. Turner (plexq) Assigned to: Nobody/Anonymous (nobody) Summary: Calling socket.recv() with a large number breaks Initial Comment: I have a backup script that calls socket.recv() passing the amount of data that is left to get for a given file as the argument. For very large files (I have one here that is 1.9Gig) it seems to break horribly after receiving about 130Meg. I have tried to track it down precisely with basic debugging (putting in print statements in the python code) but it just seams to freak out around the 130meg mark, and it just doesn't make sense. If I change the argument passed to recv to 32767 it works just fine. I have attatched the loop that reads data from the socket (In a working state, the bad code is commented out). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:08 Message: Logged In: YES user_id=1188172 Applied your proposed wording in rev.41818/41819. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 20:07 Message: Logged In: YES user_id=752496 This is a documentation bug; something the user should be "warned" about. This caught me once, and two different persons asked about this in #python, so maybe we should put something like the following in the recv() docs. """ For best match with hardware and network realities, the value of "buffer" should be a relatively small power of 2, for example, 4096. """ If you think the wording is right, just assign the bug to me, I'll take care of it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-13 16:11 Message: Logged In: YES user_id=31435 As Jeremy implied at the start, someone needs to demonstrate that "the bug" is actually in Python, not in your platform's implementation of sockets. If a C program displays the same behavior, your complaint is with your platform socket implementation. Sockets are low-level gimmicks, which is why Jeremy expected a C program to fail the same way. ---------------------------------------------------------------------- Comment By: Dmitry Dvoinikov (targeted) Date: 2004-09-13 13:17 Message: Logged In: YES user_id=1120792 I've also been hit by this problem, not at a 130Meg read, but at a mere 10Meg. Because of that I had to change my code to read many small chunks rather than a single blob and that fixed it. Still, I disagree with tim_one. If recv() is limited with the amount of data it can read per call, it should be set and documented, otherwise it is a bug and the call is unreliable. Nobody has to follow the decribed "best-practice" of reading small chunks, it actually worsens code quality, and what's worse - it makes other stuff break. Example - I was using the SimpleXMLRPCServer (Lib/SimpleXMLRPCServer.py), and it contains the following line at it's heart: data = self.rfile.read(int(self.headers["content-length"])) Guess what was happening with requests with content-length larger than 10Meg (in my case). I've aso thought the problem was with max() instead of min(), but as tim_one rightfully pointed out, this was a desired behaviour. Ironically though, replacing max() with min() fixes the problem as there is no more huge reads at lower level. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-27 02:41 Message: Logged In: YES user_id=31435 potterru, I don't believe plexq was using _fileobject.read() -- he said he was using socket.recv(), and all the comments later were consistent with that. The code you found does appear to *intend* max(): code following the snippet you quoted clearly expects that it may have read more than "left" bytes, and it would not be worrying about that had min() been intended. I agree the code is pretty inscrutable regardless, but we'd have to ask Guido why he wrote it that way. In any case, since this bug report is about socket.recv(), if you want to make a case that _fileobject.read() is buggy you should open a new report for that. ---------------------------------------------------------------------- Comment By: Igor E. Poteryaev (potterru) Date: 2004-07-26 13:23 Message: Logged In: YES user_id=48596 It looks like bug in module socket.py in _fileobject.read method. ... while True:     left = size - buf_len     recv_size = max(self._rbufsize, left)     data = self._sock.recv(recv_size) This code should read not more than *left* or *buffer size* So, it should be min instead of max ! Should I file a bug/patch for this ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-18 20:51 Message: Logged In: YES user_id=31435 I assume you're running on Linux. Python's implementation of recv asks the platform malloc for a buffer of the size requested, and raises an exception if malloc returns NULL. Unfortunately, malloc on Linux has a nasty habit of returning non-NULL even if there's no chance you can actually use the amount of memory requested. There's really nothing Python can do about that. So back to Jeremy's comment: try the same thing in C. If you get ridiculous behavior there too, it's a platform C/OS bug, and Python won't be able to hide it from you. ---------------------------------------------------------------------- Comment By: Alex R.M. Turner (plexq) Date: 2003-06-18 20:22 Message: Logged In: YES user_id=60034 That as maybe - it might be worth putting a suggested maximum in the docs. However I would say that given that an IPv6 packet could be as large as 2Gig, it's not unreasonable to ask for a packet as large as 1 Gig. Wether the problem is in glibc or python I don't know, although it seems that asking for a buffer of 1.3 Gig in size, and passing that to recv() would be odd behaviour on a current system in C given that most systems couldn't allocate that much memory to a buffer ;). I have written fairly extensive socket code in C/C++ before, and I never used anything larger than 65536 for the obvious reason that you can't receive anything bigger than that in IPv4 (and most NICs can't handle anything that big either). I figured it would be interesting to see what happened :). I have a penchant for being the only person in history to do quite a few things apparently! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-18 18:29 Message: Logged In: YES user_id=31435 BTW, if you're new to socket programming, do read Python's socket programming HOWTO: http://www.amk.ca/python/howto/sockets/ I expect you're the only person in history to try passing such a large value to recv() -- even if it worked, you'd almost certainly run out of memory trying to allocate buffer space for 1.9GB. sockets are a low-level facility, and it's common to pass a relatively small power of 2 (for best match with hardware and network realities). ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-18 18:02 Message: Logged In: YES user_id=31392 What happens when you write a C program that does the same thing? I expect you'll see similar problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:10:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:10:08 -0800 Subject: [ python-Bugs-574241 ] Automated daily documentation builds Message-ID: Bugs item #574241, was opened at 2002-06-26 21:58 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:10 Message: Logged In: YES user_id=1188172 This seems to have been done now, see http://docs.python.org/dev/. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 23:45 Message: Logged In: YES user_id=80475 Fred, I had thought you had made a job for this but it doesn't appear to be running on a regular basis. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-19 16:49 Message: Logged In: YES user_id=6656 I'd have thought it was an entirely reasonable use of the starship, but I guess you could ask on the crew list first if you want to be really polite... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 08:39 Message: Logged In: YES user_id=3066 Perhaps that's good enough, though I've generally done updates from the latest CVS. Would anyone object to my setting up a cronjob to perform the build on starship? It appears that sufficient software is installed on that machine to perform the build (and much faster than on anything I have). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-19 08:03 Message: Logged In: YES user_id=21627 For a daily build, it is IMO sufficient to use the anonymous CVS - it may be a few hours behind, but you'ld have to wait a full day anyway for the changes to show up. If somebody builds the documentation elsewhere, a cronjob on python.org could pick it up from "elsewhere", which would mean no access to python.org is necessary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 05:18 Message: Logged In: YES user_id=3066 At this point it is trivial to checkout and build the documentation automatically, with one caveat. The script would need to be able to do an authenticated checkout from SourceForge, and needs to be able to log into the python.org webserver as one of the webmasters to install the fresh tarball. While an anonymous checkout of the documentation sources is possible, it's out of date by several hours (as long as we use SF's CVS). That means the script needs to run within the context of an ssh-agent with the right keys added, or the keys must not have passphrases. I'm too paranoid to live without passphrases on my private keys, and I really haven't thought about how to run a cron job such that it can use a properly populated ssh-agent, but that seems conceptually fragile. (Who *always* has such an agent running, not just when logged in directly?) The documentation build is too heavy a process to run on the python.org webserver itself, and that still relies on being able to do an authenticated checkout from SF. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-17 04:36 Message: Logged In: YES user_id=80475 With your new automation scripts is it now possible to run a daily cron job? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 21:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to python-docs at python.org, and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-30 20:46 Message: Logged In: YES user_id=21627 I don't think this is possible. Automatic rebuilding of the documentation will likely fail frequently, because of errors in the tex input. OTOH, if somebody volunteers to produce the documentation automatically somewhere in the world (and fixes errors found during the rebuild), then it would be easy to mirror those on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:16:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:16:09 -0800 Subject: [ python-Bugs-839585 ] String formatting operator % badly documented Message-ID: Bugs item #839585, was opened at 2003-11-10 23:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: String formatting operator % badly documented Initial Comment: Hello everyone! The % operator works with strings, but this is hard to find in the documentation (Library Reference 2.2.6.2). Really bad is, that an operator should be documented in the Language Reference, where it isn't. Lang-Ref "5.6 Binary arithmetic operations" is labeled wrong, as it also describes the non-arithmetic operations of + and * but seems to know nothing about % under that aspect... It is actually indirectly saying that there is no further non-arithmetic operation - but there is: %. Rob ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:16 Message: Logged In: YES user_id=1188172 Applied corrected patch in rev. 41820/41821. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-03-20 20:00 Message: Logged In: YES user_id=99874 Two thoughts I had after attaching that patch. (1) If there's a way to create inter-document links, that would be a good idea. I don't know of one. (2) If the format of this patch is a pain, let me know. All I'm doing is adding one paragraph. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-03-20 19:52 Message: Logged In: YES user_id=99874 Good point, this has long bothered me too. I'm attaching a patch. Fred, can you review (make sure I didn't introduce broken tex syntax) and check in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:28:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:28:13 -0800 Subject: [ python-Bugs-839075 ] Document that highly recursive data cannot be pickled Message-ID: Bugs item #839075, was opened at 2003-11-10 08:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839075&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simon David Burton (simonb1) Assigned to: Nobody/Anonymous (nobody) Summary: Document that highly recursive data cannot be pickled Initial Comment: Make a note in section 3.4.14 Python Library Reference (perhaps a footnote?) that higly recursive data stuctures cannot be pickled. Setting the stack limit helps a bit, but does not scale to large networks of data. eg. #!/usr/bin/env python import cPickle as pickle #import pickle import os #sys.setrecursionlimit(4000) N = 2048 print "building..." nest = [ [] for i in range(N) ] for i in range(N): for j in range(N): nest[i].append( nest[j] ) print "dumping..." file = open("nest.pkl","wb") try: pickle.dump( nest, file ) except RuntimeError, e: print e ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:28 Message: Logged In: YES user_id=1188172 Added a note to the docs in rev. 41822/41823. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839075&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:31:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:31:57 -0800 Subject: [ python-Bugs-845342 ] os.exec* and first 'arg' Message-ID: Bugs item #845342, was opened at 2003-11-19 20:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845342&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: os.exec* and first 'arg' Initial Comment: The current I'd suggest the following change to the docstrings for the exec* functions, because I think it's quite easy to get bitten: execv(...) execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings (NOTE: the first argument is analoguous to sys.argv[0], *not* sys.argv[1]!) instead of: execv(...) execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:31 Message: Logged In: YES user_id=1188172 This is covered in the Library Manual. Docstrings aren't meant to be complete, just quick overviews of what the functions do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845342&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:37:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:37:12 -0800 Subject: [ python-Bugs-954981 ] Error in urllib2 Examples Message-ID: Bugs item #954981, was opened at 2004-05-16 23:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=954981&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Phillip (phillip_) Assigned to: Nobody/Anonymous (nobody) Summary: Error in urllib2 Examples Initial Comment: I'll quote from the urllib2 examples: >>> Here we are sending a data-stream to the stdin of a CGI and reading the data it returns to us: >>> import urllib2 >>> req = urllib2.Request(url='https://localhost/cgi-bin/test.cgi', ... data='This data is passed to stdin of the CGI') >>> f = urllib2.urlopen(req) ... <<< urllib2 returns: urllib2.URLError: (This is the Errormsg in 2.3.3, 2.2.3 is a different syntax but says the same. This is seriously misleading, as it implies that somehow urllib2 can handle https, which it can't in this manner. At least not in the way exampled here. Please correct or delete this example. It would be nice if you could provide a working example for handling https. Examples are a good thing in the whole httplib / urllib / urllib2 area, since it appears somewhat hard to overlook. I'm sorry I can't provide a working version of this example, as I am trying to figure out how to handle https myself. Anyway, it's a documentation bug and needs fixing. Thanks. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:37 Message: Logged In: YES user_id=1188172 Added the note Martin suggested in rev. 41824/41825. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-06-03 11:38 Message: Logged In: YES user_id=21627 What operating system are you using? The example works fine for me, when modified to use an actual web server: >>> urllib2.Request("https://sourceforge.net/tracker/index.php","func=detail&aid=954981&group_id=5470&atid=105470") >>> r=urllib2.Request("https://sourceforge.net/tracker/index.php","func=detail&aid=954981&group_id=5470&atid=105470") >>> f=urllib2.urlopen(r) >>> f.read() Can you provide the complete traceback? For https to work, your Python installation must support SSL. For this, import _ssl must succeed. For that to work, OpenSSL must have been used when Python was built. I can add a text to the documentation indicating that the example fails if the Python installation does not support SSL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=954981&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:44:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:44:58 -0800 Subject: [ python-Bugs-489256 ] Lib/profile.doc should be updated Message-ID: Bugs item #489256, was opened at 2001-12-05 06:51 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:44 Message: Logged In: YES user_id=1188172 Commented out the notes about the old profiler in rev. 41826. Closing this bug now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-10 10:07 Message: Logged In: YES user_id=469548 I just checked and there was no information in profile.doc that wasn't in the library reference, so I've removed it now. I've also replaced help() along the lines of what you suggested. Just one more question: could we remove the "How Is This Profiler Different From The Old Profiler?" subsection from the library reference? It's hardly relevant, considering that the Old Profiler was last seen in Python 1.1 (!). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-10 04:07 Message: Logged In: YES user_id=3066 Removing profile.doc sounds fine to me. The only thing that really needs to be done prior to removal is to make sure all the (still current) information in profile.doc is represented in the library documentation. The help() function should probably be replaced with something that refers the user to the library documentation, rather than removing the function. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:52:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:52:13 -0800 Subject: [ python-Bugs-922690 ] package manager page outdated link Message-ID: Bugs item #922690, was opened at 2004-03-24 21:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: package manager page outdated link Initial Comment: The page http://www.python.org/packman/ has outdated links to Bob Ippolito's page. The correct link appears to be http://undefined.org/python/ (which includes links to various versions of the packages and to descriptions of the same). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:52 Message: Logged In: YES user_id=1188172 This is still a problem. The packman page needs update, as it seems. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-03-30 18:57 Message: Logged In: YES user_id=593130 To supplement the summary: the two links (xml and html) on the bottom of the packman page work but they are specific to (an older? verseion) the pimp package. The higher link suggested as a substitue lists other packages, including some that appear to have been extracted from pimp. Since the current page references aeve 0.0.3 while the suggested link references aeve 0.0.4, the suggest change seems proper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 From noreply at sourceforge.net Tue Dec 27 00:56:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 15:56:28 -0800 Subject: [ python-Bugs-1389673 ] Incorrect docs for return values of set update methods Message-ID: Bugs item #1389673, was opened at 2005-12-24 19:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect docs for return values of set update methods Initial Comment: The documentation for set.update(), set.intersection_update(), set.difference_update() and set.symmetric_difference_update currently (as of r41806) states that these methods all return the updated set, implying that this is a not-in-place change. In fact, these methods do operate in place, each one of them returning None. The attached diff (against Doc/lib/libstdtypes.tex, r41806) fixes this, making it clear that these are in-place operations. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 00:56 Message: Logged In: YES user_id=1188172 Thanks, applied the patch in rev. 41827/41828. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389673&group_id=5470 From noreply at sourceforge.net Tue Dec 27 01:00:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 16:00:04 -0800 Subject: [ python-Bugs-1385004 ] exec statement link in index broken Message-ID: Bugs item #1385004, was opened at 2005-12-19 10:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385004&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: exec statement link in index broken Initial Comment: In library reference index: http://www.python.org/doc/2.4.2/lib/genindex.html "exec statement" points to http://www.python.org/doc/2.4.2/lib/bltin-code-objects.html#l2h-265 Which seems wrong. (2.4 docs already had the same). -Harri ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:00 Message: Logged In: YES user_id=1188172 That's correct in a sense because the exec statement isn't described in the Library Manual. The index entry links to "Code Objects" because exec is mentioned there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385004&group_id=5470 From noreply at sourceforge.net Tue Dec 27 01:03:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 16:03:40 -0800 Subject: [ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError Message-ID: Bugs item #1386675, was opened at 2005-12-21 02:41 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:03 Message: Logged In: YES user_id=1188172 Corrected in rev. 41829/41830. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-12-26 03:36 Message: Logged In: YES user_id=552329 I don't see what purpose there is in having the documentation say that EnvironmentError is raised, when a subclass is. _winreg is still marked as a temporary module to be replaced, so it's hard to believe it's some sort of future-proofing. One could say that Exception is raised, since EnvironmentError is a subclass of Exception, but explicit is better than implicit, right? (import _winreg fails on non-Windows platforms, so I don't see how it could be for cross-platform reasons, either). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 12:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 From noreply at sourceforge.net Tue Dec 27 01:06:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 16:06:38 -0800 Subject: [ python-Bugs-1375599 ] Tutorial errors Message-ID: Bugs item #1375599, was opened at 2005-12-07 19:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375599&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Glen Kaukola (gkaukola) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial errors Initial Comment: In section 1 of the tutorial, it says this: "Python enables programs to written compactly and readably." It should probably read like so: "Python enables programs to be written compactly and readably." I'd like it even better like so: "Python enables programs to be compact and readable." Also, even though it probably doesn't matter really since it's just an example, in your Fibonacci sequence example in section 4.6 it should probably be "while b <= n" as opposed to "while b < n". Because if n == 1, nothing is spit out. But even then it still wouldn't handle 0. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:06 Message: Logged In: YES user_id=1188172 Corrected the 2.4 branch version in rev. 41831. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-08 07:05 Message: Logged In: YES user_id=33168 Not sure where you are seeing the grammar problem in section 1. It is fixed in SVN and on this page: http://docs.python.org/tut/tut.html Presumably you are looking at an old version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375599&group_id=5470 From noreply at sourceforge.net Tue Dec 27 01:10:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 16:10:19 -0800 Subject: [ python-Bugs-1152424 ] Dict docstring error Python-2.3.5 Message-ID: Bugs item #1152424, was opened at 2005-02-26 17:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Dict docstring error Python-2.3.5 Initial Comment: Minor error, epydoc reports the following: =========================================================================== In __builtin__.dict docstring: --------------------------------------------------------------------------- L3: Error: Improper paragraph indentation. L5: Error: Improper paragraph indentation. L7: Error: Improper paragraph indentation. L9: Error: Improper paragraph indentation. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:10 Message: Logged In: YES user_id=1188172 I can't find anything wrong with that docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&group_id=5470 From noreply at sourceforge.net Tue Dec 27 04:00:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 19:00:17 -0800 Subject: [ python-Bugs-1390991 ] lambda functions confused when mapped in dictionary object Message-ID: Bugs item #1390991, was opened at 2005-12-27 03: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=1390991&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Samuel Hsiung (shsiung) Assigned to: Nobody/Anonymous (nobody) Summary: lambda functions confused when mapped in dictionary object Initial Comment: ***Background*** Lambda functions wrapped around different module functions overwrite each other when mapped one at a time in a dictionary object. Python Version: 2.4.2 ***Duplication Instructions*** 1. Setup ===module foo.py=== def callme(x): print "foo called!" print x ===module bar.py=== def callme(x): print "bar called!" print x ===module call.py=== import foo, bar api = {} modules = (foo, bar) for module in modules: api[module] = lambda x: module.callme(x) print '%s mapped to %s' % (module, api[module]) api[foo]('above line should be foo') api[bar]('above line should be bar') print "foo lambda: %s" % api[foo] print "bar lambda: %s" % api[bar] 2. Execution => python call.py mapped to at 0xb7f7abc4> mapped to at 0xb7f7abfc> bar called! above line should be foo bar called! above line should be bar foo lambda: at 0xb7f7abc4> bar lambda: at 0xb7f7abfc> 3. Expected behaviour foo should have been called, followed by bar; instead bar was called twice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390991&group_id=5470 From noreply at sourceforge.net Tue Dec 27 04:52:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 19:52:32 -0800 Subject: [ python-Bugs-1152424 ] Dict docstring error Python-2.3.5 Message-ID: Bugs item #1152424, was opened at 2005-02-26 11:19 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Dict docstring error Python-2.3.5 Initial Comment: Minor error, epydoc reports the following: =========================================================================== In __builtin__.dict docstring: --------------------------------------------------------------------------- L3: Error: Improper paragraph indentation. L5: Error: Improper paragraph indentation. L7: Error: Improper paragraph indentation. L9: Error: Improper paragraph indentation. ---------------------------------------------------------------------- >Comment By: Colin J. Williams (cjwhrh) Date: 2005-12-26 22:52 Message: Logged In: YES user_id=285587 This was not an important problem ten months ago but I suggest that the reported problem needs attention - I no longer have 2.3 installed. Assuming for a moment that there is no problem with the doc string then there was a problem with the epydoc/python combination. Shouldn't the problem have been passed on the the epydoc people? Colin W. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-26 19:10 Message: Logged In: YES user_id=1188172 I can't find anything wrong with that docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&group_id=5470 From noreply at sourceforge.net Tue Dec 27 09:08:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 00:08:22 -0800 Subject: [ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError Message-ID: Bugs item #1386675, was opened at 2005-12-21 02:41 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-27 09:08 Message: Logged In: YES user_id=38376 The original checkin used EnvironmentError in both the documentation and the docstrings, so this is not a result of some accidental editing. Since a good documentation policy for a portable language is to document intended usage, not implementation artifacts, you should at least check with the original authors before you make the documentation depend on the current CPython implementation. (and no, using EnvironmentError is an entirely different thing than using Exception. Can we keep the hyperbolic arguments on comp.lang.python, please?) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:03 Message: Logged In: YES user_id=1188172 Corrected in rev. 41829/41830. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-12-26 03:36 Message: Logged In: YES user_id=552329 I don't see what purpose there is in having the documentation say that EnvironmentError is raised, when a subclass is. _winreg is still marked as a temporary module to be replaced, so it's hard to believe it's some sort of future-proofing. One could say that Exception is raised, since EnvironmentError is a subclass of Exception, but explicit is better than implicit, right? (import _winreg fails on non-Windows platforms, so I don't see how it could be for cross-platform reasons, either). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 12:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 From noreply at sourceforge.net Tue Dec 27 14:48:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 05:48:01 -0800 Subject: [ python-Bugs-1283289 ] PyArg_ParseTupleAndKeywords gives misleading error message Message-ID: Bugs item #1283289, was opened at 2005-09-06 21:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283289&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: japierro (japierro) Assigned to: Martin v. L?wis (loewis) Summary: PyArg_ParseTupleAndKeywords gives misleading error message Initial Comment: Python 2.3.3 on Windows XP If the user supplies one valid and one invalid keyword to a function that defines two required keyword arguments, PyArg_ParseTupleAndKeywords will raise this exception: TypeError: function takes exactly 2 arguments (1 given) If, in getargs.c, vgetargskeywords, the check for "extraneous keywords" were done near the top of the function, a more meaningful exception would be thrown: TypeError: 'bad' is an invalid keyword argument for this function ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-12-27 14:48 Message: Logged In: YES user_id=21627 I agree that the error message should be fixed; this is even an 'XXX' comment ("an this isn't a bug?"). Unfortunately, just looking for bad keyword arguments is not enough - it might even be that an optional keyword argument is supplied, and still the error message is confusing, e.g. for >>> re.compile("a").match(pos=10) Traceback (most recent call last): File "", line 1, in TypeError: match() takes at least 1 argument (0 given) Instead, I think the error message should read: TypeError: "pattern" argument for match() is missing as we know exactly what "meaning" the missing argument has. This might still be unspecific if multiple required arguments are missing, but I think just giving the first one would be informative enough - or else it could read TypeError: "pattern" argument for match() is missing (+2 more) if there are 2 more missing. Yet alternatively, it could read TypeError: required arguments for match() missing: 'pattern', 'foo', 'bar' Patches in this direction are welcome; the precise wording proposal should be mentioned on python-dev. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 20:43 Message: Logged In: YES user_id=1188172 Any opinions? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283289&group_id=5470 From noreply at sourceforge.net Tue Dec 27 18:26:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 09:26:53 -0800 Subject: [ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError Message-ID: Bugs item #1386675, was opened at 2005-12-21 02:41 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Open >Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 18:26 Message: Logged In: YES user_id=1188172 You're right. I reverted the checkin, assigning to Fred. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-27 09:08 Message: Logged In: YES user_id=38376 The original checkin used EnvironmentError in both the documentation and the docstrings, so this is not a result of some accidental editing. Since a good documentation policy for a portable language is to document intended usage, not implementation artifacts, you should at least check with the original authors before you make the documentation depend on the current CPython implementation. (and no, using EnvironmentError is an entirely different thing than using Exception. Can we keep the hyperbolic arguments on comp.lang.python, please?) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 01:03 Message: Logged In: YES user_id=1188172 Corrected in rev. 41829/41830. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-12-26 03:36 Message: Logged In: YES user_id=552329 I don't see what purpose there is in having the documentation say that EnvironmentError is raised, when a subclass is. _winreg is still marked as a temporary module to be replaced, so it's hard to believe it's some sort of future-proofing. One could say that Exception is raised, since EnvironmentError is a subclass of Exception, but explicit is better than implicit, right? (import _winreg fails on non-Windows platforms, so I don't see how it could be for cross-platform reasons, either). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 12:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 From noreply at sourceforge.net Tue Dec 27 18:37:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 09:37:42 -0800 Subject: [ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME Message-ID: Bugs item #959576, was opened at 2004-05-24 19:16 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Can't build Python on POSIX w/o $HOME Initial Comment: If you're building Python on os.name == 'posix' but when there is no $HOME defined in your environment, you cannot build Python. This is because in the bowels of distutils, you end up in check_environ(), which has these lines: if os.name == 'posix' and not os.environ.has_key('HOME'): import pwd os.environ['HOME'] = pwd.getpwuid(os.getuid())[5] However, in a from-scratch build, the pwd module isn't built by the time you get here. I found this when using SCons to build Python, since by default the enclosing environment isn't passed to subprocesses. I can work around this in my builds but Python's setup.py should probably synthesize a $HOME if one doesn't exist. (Or maybe someone has a better idea for a workaround). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 18:37 Message: Logged In: YES user_id=1188172 I made the suggested change in revision 41834/41835. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-02 10:57 Message: Logged In: YES user_id=21627 Making pwd builtin is fine with me. Make sure you move the line to the other builtin modules, and add a comment telling why it is need (i.e. when HOME isn't set). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:04 Message: Logged In: YES user_id=1188172 Well, pwd will be built-in then, if that's a problem. Assigning to loewis to look over it. ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:28 Message: Logged In: YES user_id=59465 Let me revise that last comment. There are some build differences when this is done. Uncommenting pwd in Setup.dist allows python to build, but the 'pwd' extension (and pwd.so) does not get built. And pwdmodule.o is ar'd into libpython2.4.a (& linked into libpython2.4.so) ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:14 Message: Logged In: YES user_id=59465 I had this problem, too. The fix proposed by birkenfeld on 9/22 works for me. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:19 Message: Logged In: YES user_id=1188172 Seems that the pwdmodule entry in Modules/Setup.dist must be uncommented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 From noreply at sourceforge.net Tue Dec 27 18:38:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 09:38:39 -0800 Subject: [ python-Bugs-999767 ] Setup.local ignored by setup.py Message-ID: Bugs item #999767, was opened at 2004-07-29 00:06 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stephan A. Terre (sfiedler) >Assigned to: Martin v. L?wis (loewis) Summary: Setup.local ignored by setup.py Initial Comment: This applies to Python 2.2.x, 2.3.x, and 2.4a1. Platforms seem to be all Unix flavors. I have zlib, readline, and Tk in an unusual location. There are also often older versions in the usual locations (/usr/local/lib, etc.). I put -L and -I flags pointing to the desired location of these libraries in entries for the appropriate extension modules in Setup.local, per the README. I specify all three extension modules as *shared* . When I build, the extension modules I specify in Setup.local get built twice: once directly from the Makefile, with the flags I request in Setup.local, then again from setup.py's build_ext phase, with the default flags. The second build is what's installed, so I end up using the wrong version of libz, libreadline, and libtk . The problem appears to be around line 152 of setup.py (CVS revision 1.190). There is code to ignore modules defined in Modules/Setup, but not modules defined in Modules/Setup.local . I'm not familiar with the text_file.TextFile class, so there may be a better way to do this, but one the fix is to loop over ['Modules/Setup', 'Modules/Setup.local'] rather than only reading Modules/Setup. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 18:38 Message: Logged In: YES user_id=1188172 I think that's reasonable. Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 From noreply at sourceforge.net Tue Dec 27 19:17:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 10:17:37 -0800 Subject: [ python-Bugs-999767 ] Setup.local ignored by setup.py Message-ID: Bugs item #999767, was opened at 2004-07-29 00:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stephan A. Terre (sfiedler) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Setup.local ignored by setup.py Initial Comment: This applies to Python 2.2.x, 2.3.x, and 2.4a1. Platforms seem to be all Unix flavors. I have zlib, readline, and Tk in an unusual location. There are also often older versions in the usual locations (/usr/local/lib, etc.). I put -L and -I flags pointing to the desired location of these libraries in entries for the appropriate extension modules in Setup.local, per the README. I specify all three extension modules as *shared* . When I build, the extension modules I specify in Setup.local get built twice: once directly from the Makefile, with the flags I request in Setup.local, then again from setup.py's build_ext phase, with the default flags. The second build is what's installed, so I end up using the wrong version of libz, libreadline, and libtk . The problem appears to be around line 152 of setup.py (CVS revision 1.190). There is code to ignore modules defined in Modules/Setup, but not modules defined in Modules/Setup.local . I'm not familiar with the text_file.TextFile class, so there may be a better way to do this, but one the fix is to loop over ['Modules/Setup', 'Modules/Setup.local'] rather than only reading Modules/Setup. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-12-27 19:17 Message: Logged In: YES user_id=21627 I agree; go ahead and make that change. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 18:38 Message: Logged In: YES user_id=1188172 I think that's reasonable. Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 From noreply at sourceforge.net Tue Dec 27 19:24:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 10:24:46 -0800 Subject: [ python-Bugs-999767 ] Setup.local ignored by setup.py Message-ID: Bugs item #999767, was opened at 2004-07-29 00:06 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stephan A. Terre (sfiedler) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Setup.local ignored by setup.py Initial Comment: This applies to Python 2.2.x, 2.3.x, and 2.4a1. Platforms seem to be all Unix flavors. I have zlib, readline, and Tk in an unusual location. There are also often older versions in the usual locations (/usr/local/lib, etc.). I put -L and -I flags pointing to the desired location of these libraries in entries for the appropriate extension modules in Setup.local, per the README. I specify all three extension modules as *shared* . When I build, the extension modules I specify in Setup.local get built twice: once directly from the Makefile, with the flags I request in Setup.local, then again from setup.py's build_ext phase, with the default flags. The second build is what's installed, so I end up using the wrong version of libz, libreadline, and libtk . The problem appears to be around line 152 of setup.py (CVS revision 1.190). There is code to ignore modules defined in Modules/Setup, but not modules defined in Modules/Setup.local . I'm not familiar with the text_file.TextFile class, so there may be a better way to do this, but one the fix is to loop over ['Modules/Setup', 'Modules/Setup.local'] rather than only reading Modules/Setup. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 19:24 Message: Logged In: YES user_id=1188172 Fixed in rev. 41837/41838. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-12-27 19:17 Message: Logged In: YES user_id=21627 I agree; go ahead and make that change. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 18:38 Message: Logged In: YES user_id=1188172 I think that's reasonable. Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470 From noreply at sourceforge.net Wed Dec 28 01:03:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 16:03:34 -0800 Subject: [ python-Bugs-1390321 ] README mention --without-cxx Message-ID: Bugs item #1390321, was opened at 2005-12-26 05:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: README mention --without-cxx Initial Comment: This just verified against HEAD: ./configure fails on Linux without g++ installed unless --without-cxx given. README should mention this. Error is checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables Inside config.log it says: gcc: installation problem, cannot exec 'cc1plus': No such file or directory (There's been some discussion about not requiring C++ installation by default -- until that's settled, we should at least update the README.) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-12-28 01:03 Message: Logged In: YES user_id=21627 The real solution to this problem is that configure shouldn't fail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&group_id=5470 From noreply at sourceforge.net Wed Dec 28 01:06:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 16:06:22 -0800 Subject: [ python-Bugs-1376400 ] test_struct crashed, py2.3.5, solaris 10 Message-ID: Bugs item #1376400, was opened at 2005-12-08 17:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: rrogans (rrogans) Assigned to: Nobody/Anonymous (nobody) Summary: test_struct crashed, py2.3.5, solaris 10 Initial Comment: Hi, I am building python 2.3.5 on solaris 10 using gcc 3.3.2. Run I perform the test I get one test failure - test_struct crashes. Rgds, Richard >>>>>>>>>>>> trying std qQ on 1471797217424382203 == 0x146CDFC575FD18FBL trying std qQ on 1471797217424382204 == 0x146CDFC575FD18FCL trying std qQ on 1471797217424382205 == 0x146CDFC575FD18FDL test test_struct crashed -- exceptions.OverflowError: math range error Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals (), []) File "/home/richardr/app/Python- 2.3.5/Lib/test/test_struct.py", line 439, in ? test_705836() File "/home/richardr/app/Python- 2.3.5/Lib/test/test_struct.py", line 424, in test_705836 big = math.ldexp(big, 127 - 23) OverflowError: math range error 1 test failed: test_struct <<<<<<<<<<< ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-12-28 01:06 Message: Logged In: YES user_id=21627 Also, Python 2.3 is no longer maintained. So unless this problem also shows up with 2.4, we are unlikely to take any action. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 21:15 Message: Logged In: YES user_id=33168 Could you try disabling optimization and rebuilding python? Also, depending on which compiler you are using, ensure that you are using strict math. Sometimes the option is -ieee I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376400&group_id=5470 From noreply at sourceforge.net Wed Dec 28 01:12:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 16:12:16 -0800 Subject: [ python-Feature Requests-1303434 ] Please include pdb with windows distribution Message-ID: Feature Requests item #1303434, was opened at 2005-09-24 21:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-12-28 01:12 Message: Logged In: YES user_id=21627 Update: distribution in a separate zipfile would be possible, provided that a patch to the build process (in Tools/msi/msi.py) would be contributed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-27 22:03 Message: Logged In: YES user_id=21627 Including the PDB files in the MSI is probably not acceptable to the majority of the users. python24.pdb is 3.5MiB in size, so the MSI file to download would grow considerably. Why do you need the PDB file in the first place? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 From noreply at sourceforge.net Wed Dec 28 03:04:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 18:04:59 -0800 Subject: [ python-Bugs-1391608 ] missing module names in email package Message-ID: Bugs item #1391608, was opened at 2005-12-27 23:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: missing module names in email package Initial Comment: Documentation for modules inside the email package lacks reference to module name in title (and body too). By example, there is no clue in 12.2.1 that the Message class being described is contained in the email.Message module. Or 12.2.2 doesnt menction that FeedParser, HeaderParser and Parser are all classes contained in module email.Parser. And so on. Looking at other similar standard packages (like curses) seems that the module name should appear first in the title. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470 From noreply at sourceforge.net Wed Dec 28 12:01:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 03:01:05 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 12: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=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Wed Dec 28 12:02:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 03:02:01 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 12:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core >Group: Python 2.5 Status: Open Resolution: None >Priority: 9 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 12:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Wed Dec 28 14:41:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 05:41:58 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 20:01 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 22:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Wed Dec 28 15:04:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 06:04:08 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 20:01 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 23:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 22:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Wed Dec 28 16:55:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 07:55:57 -0800 Subject: [ python-Feature Requests-1367936 ] split() string method has two splitting algorithms Message-ID: Feature Requests item #1367936, was opened at 2005-11-28 00:13 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: crackwitz (crackwitz) Assigned to: Nobody/Anonymous (nobody) Summary: split() string method has two splitting algorithms Initial Comment: The docs of Python 2.4.2 for .split([sep [,maxsplit]]) say: "If sep is not specified or is None, a different splitting algorithm is applied." I would like to see that behavior exposed and consistent, i.e. stripping (new key strip=...?) independent of whether sep is None or not. Making it consistent could break existing code because people already built on split()'s special behavior. You could say strip=None by default and only keep switching if strip==None. I don't like this magic behavior though because there's no reason for it to exist. # this is now (Python v2.4.2) ' foo bar '.split() # => ['foo', 'bar'] ' foo bar '.split(' ') # => ['', 'foo', '', 'bar', ''] # this is how I would like it to be ' foo bar '.split(strip=True) # => ['foo', 'bar'] ' foo bar '.split(strip=False) # => ['', 'foo', '', 'bar', ''] # compatibility preserved (strip=None by default): ' foo bar '.split(strip=None) # => ['foo', 'bar'] ' foo bar '.split(' ', strip=None) # => ['', 'foo', '', 'bar', ''] what do you think? ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-12-28 10:55 Message: Logged In: YES user_id=99874 I'm -1 on changing it at all. I do understand how the unnecessary inconsistancy can be grating, but it is clearly documented, it is backward compatible, and it is useful. Pragmatism wins out over theoretical consistancy in my opinion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-29 23:10 Message: Logged In: YES user_id=80475 While unfortunate, this function already suffers from excess complexity. Changing the behavior and adding backwards compatability features would make the situation worse. Also, the two different behaviors were not accidental. Someone put them in for a reason. There may be orthogonal use cases. Ideally, that need would have been been through two different functions/methods. But, if you change the behavior, you're likely breaking an entire class of use cases. So, I'm -1 on mucking with this prior to Py3.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470 From noreply at sourceforge.net Wed Dec 28 17:00:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 08:00:28 -0800 Subject: [ python-Bugs-1157169 ] csv Sniffer returns bad dialect? Message-ID: Bugs item #1157169, was opened at 2005-03-05 02:14 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Skip Montanaro (montanaro) Summary: csv Sniffer returns bad dialect? Initial Comment: >>> d = csv.Sniffer().sniff('abc', ['\t', ',']) >>> csv.reader(['abc'], d) Traceback (most recent call last): File "", line 1, in ? TypeError: bad argument type for built-in operation If the 'delimiters' argument to sniff() is left out then the TypeError is not raised. Not sure what's going on here. A few other nits: sniff() seems to be misdocumented. It cannot return None. What's the point of the Sniff class? Why isn't sniff() a module level function? The library manual does not state what the iterator returned by reader() returns. It should state that generates lists of strings. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-28 10:00 Message: Logged In: YES user_id=44345 Somewhere along the way the sniff() docs apparently got fixed. The Sniff class has two methods, at least at this point. It does, in theory, also hide a couple helper methods as well. I'll look into the other problems. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157169&group_id=5470 From noreply at sourceforge.net Wed Dec 28 17:41:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 08:41:06 -0800 Subject: [ python-Feature Requests-1144057 ] future warning in commets Message-ID: Feature Requests item #1144057, was opened at 2005-02-18 16:10 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: M.-A. Lemburg (lemburg) Summary: future warning in commets Initial Comment: Python uses '#' as start of comment, generally these lines can (should) be ignored by python compiler but .. deprecation warnings are issued when comment contains non ascii letters - ord(ch) not in range 0-127 can we disable it in this situation ? ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-12-28 11:41 Message: Logged In: YES user_id=99874 Rejecting, as per lemburg. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-23 08:44 Message: Logged In: YES user_id=38388 +1, this request is not in line with the source code encoding PEP. Rejecting the request. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-02-23 08:33 Message: Logged In: YES user_id=99874 I agree with doerwalter. If the file is in ascii, then it should be in ascii... even comments. If it's not in ascii, that's fine, but it needs to be marked as to what encoding it IS in. I don't happen to know of any encodings in which certain bytes with the high bit set indicate newlines, but imagine that there were one. The newline marks the end of the comment, so it makes a syntactic difference in the program... we must be able to recognize newlines in order to parse the file. And if we don't know the encoding, then how can we possibly recognize newlines? I propose rejecting the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-21 04:17 Message: Logged In: YES user_id=89016 I don't think we should change this. The encoding is something that affects the whole file not just the executable part of it. When a file that claims to be ASCII contains bytes > 0x7f there's something fishy going on, no matter where these bytes are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 From noreply at sourceforge.net Wed Dec 28 18:19:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 09:19:23 -0800 Subject: [ python-Feature Requests-739029 ] Constructor for counting things Message-ID: Feature Requests item #739029, was opened at 2003-05-16 22:22 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Constructor for counting things Initial Comment: Counting things is very common. May I suggest an alternate dictionary constructor that works like this: class BetterDictionary(dict): def bag(classobject, sequence): "Fast way to count things" b = classobject() for k in sequence: b[k] = b.get(k,0) + 1 return b bag = classmethod(bag) print BetterDictionary.bag("jack and jill went up a hill ...") A C implementation could do this very fast. ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-12-28 12:19 Message: Logged In: YES user_id=99874 I think I prefer birkenfeld's approach: create a well-tuned implementation for the collections module rather than adding yet one MORE use case to the already overburdened (yet very powerful) dict. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 10:07 Message: Logged In: YES user_id=1188172 Perhaps "bag" is a good addition to the "collections" module. ---------------------------------------------------------------------- Comment By: David Albert Torpey (dtorp) Date: 2003-08-26 14:07 Message: Logged In: YES user_id=681258 Smalltalk has a collection class called Bag that fills the same role. It is a frequently used class. The current way of doing things is too slow. Disassembly shows that the whole process involves loading a constant for 1, loading a constant for zero, loading the local variable 'b', performing an attribute lookup for 'get', loading the local variable 'k', calling 'get', running the summation, re-loading both 'b' and 'k' and doing a subscript store. Along the way, there are two dictionary lookups for the same key. All of that is just the inner loop and is wrapped in for-loop with all of its overhead. Instead, the whole thing could be done in one step at C speed: b.bag(itemlist). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-12 02:12 Message: Logged In: YES user_id=357491 I don't know if it is *that* common. Besides, as your code shows, it isn't that complex. It strikes me as a little too specific to be made a built-in dict constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470 From noreply at sourceforge.net Wed Dec 28 19:16:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 10:16:54 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 03:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-28 10:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 06:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 05:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 03:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Wed Dec 28 19:27:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 10:27:49 -0800 Subject: [ python-Feature Requests-1367936 ] split() string method has two splitting algorithms Message-ID: Feature Requests item #1367936, was opened at 2005-11-28 00:13 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: crackwitz (crackwitz) Assigned to: Nobody/Anonymous (nobody) Summary: split() string method has two splitting algorithms Initial Comment: The docs of Python 2.4.2 for .split([sep [,maxsplit]]) say: "If sep is not specified or is None, a different splitting algorithm is applied." I would like to see that behavior exposed and consistent, i.e. stripping (new key strip=...?) independent of whether sep is None or not. Making it consistent could break existing code because people already built on split()'s special behavior. You could say strip=None by default and only keep switching if strip==None. I don't like this magic behavior though because there's no reason for it to exist. # this is now (Python v2.4.2) ' foo bar '.split() # => ['foo', 'bar'] ' foo bar '.split(' ') # => ['', 'foo', '', 'bar', ''] # this is how I would like it to be ' foo bar '.split(strip=True) # => ['foo', 'bar'] ' foo bar '.split(strip=False) # => ['', 'foo', '', 'bar', ''] # compatibility preserved (strip=None by default): ' foo bar '.split(strip=None) # => ['foo', 'bar'] ' foo bar '.split(' ', strip=None) # => ['', 'foo', '', 'bar', ''] what do you think? ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-12-28 10:55 Message: Logged In: YES user_id=99874 I'm -1 on changing it at all. I do understand how the unnecessary inconsistancy can be grating, but it is clearly documented, it is backward compatible, and it is useful. Pragmatism wins out over theoretical consistancy in my opinion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-29 23:10 Message: Logged In: YES user_id=80475 While unfortunate, this function already suffers from excess complexity. Changing the behavior and adding backwards compatability features would make the situation worse. Also, the two different behaviors were not accidental. Someone put them in for a reason. There may be orthogonal use cases. Ideally, that need would have been been through two different functions/methods. But, if you change the behavior, you're likely breaking an entire class of use cases. So, I'm -1 on mucking with this prior to Py3.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470 From noreply at sourceforge.net Wed Dec 28 19:52:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 10:52:28 -0800 Subject: [ python-Bugs-1390991 ] lambda functions confused when mapped in dictionary object Message-ID: Bugs item #1390991, was opened at 2005-12-26 22:00 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390991&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Samuel Hsiung (shsiung) Assigned to: Nobody/Anonymous (nobody) Summary: lambda functions confused when mapped in dictionary object Initial Comment: ***Background*** Lambda functions wrapped around different module functions overwrite each other when mapped one at a time in a dictionary object. Python Version: 2.4.2 ***Duplication Instructions*** 1. Setup ===module foo.py=== def callme(x): print "foo called!" print x ===module bar.py=== def callme(x): print "bar called!" print x ===module call.py=== import foo, bar api = {} modules = (foo, bar) for module in modules: api[module] = lambda x: module.callme(x) print '%s mapped to %s' % (module, api[module]) api[foo]('above line should be foo') api[bar]('above line should be bar') print "foo lambda: %s" % api[foo] print "bar lambda: %s" % api[bar] 2. Execution => python call.py mapped to at 0xb7f7abc4> mapped to at 0xb7f7abfc> bar called! above line should be foo bar called! above line should be bar foo lambda: at 0xb7f7abc4> bar lambda: at 0xb7f7abfc> 3. Expected behaviour foo should have been called, followed by bar; instead bar was called twice. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-12-28 13:52 Message: Logged In: YES user_id=764593 Not a bug, just part of the ugliness of lambda and scopes, masked by a quirk of for loops. 'module' is not a parameter of the lambda, so it is looked up in the enclosing scope each time the lambda is called. for loops leave their index (in this case, 'module') set at the final value, so that value is found in the globals, and used by each of the lambdas. To get what you were expecting, try api[module]=lambda x,module=module:module.callme(x) This binds the name 'module' (for that lambda) to whatever its current value is, at least as a default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390991&group_id=5470 From noreply at sourceforge.net Wed Dec 28 20:00:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 11:00:07 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 12:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:00 Message: Logged In: YES user_id=38376 I'm not sure you can make too many assumptions about the locale in the test suite, but I'm pretty sure that it would be a good idea to let your "build robot" run the test suite twice; once with the standard C locale, and once with a non-US locale (e.g. sv_SE.utf8 which does include some odd characters, different date and money formats, and a decimal comma). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-28 19:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 15:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 14:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 12:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Wed Dec 28 20:47:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 11:47:03 -0800 Subject: [ python-Bugs-1390991 ] lambda functions confused when mapped in dictionary object Message-ID: Bugs item #1390991, was opened at 2005-12-27 04:00 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390991&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Samuel Hsiung (shsiung) Assigned to: Nobody/Anonymous (nobody) Summary: lambda functions confused when mapped in dictionary object Initial Comment: ***Background*** Lambda functions wrapped around different module functions overwrite each other when mapped one at a time in a dictionary object. Python Version: 2.4.2 ***Duplication Instructions*** 1. Setup ===module foo.py=== def callme(x): print "foo called!" print x ===module bar.py=== def callme(x): print "bar called!" print x ===module call.py=== import foo, bar api = {} modules = (foo, bar) for module in modules: api[module] = lambda x: module.callme(x) print '%s mapped to %s' % (module, api[module]) api[foo]('above line should be foo') api[bar]('above line should be bar') print "foo lambda: %s" % api[foo] print "bar lambda: %s" % api[bar] 2. Execution => python call.py mapped to at 0xb7f7abc4> mapped to at 0xb7f7abfc> bar called! above line should be foo bar called! above line should be bar foo lambda: at 0xb7f7abc4> bar lambda: at 0xb7f7abfc> 3. Expected behaviour foo should have been called, followed by bar; instead bar was called twice. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-28 20:47 Message: Logged In: YES user_id=1188172 Unfortunately, not a bug. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-12-28 19:52 Message: Logged In: YES user_id=764593 Not a bug, just part of the ugliness of lambda and scopes, masked by a quirk of for loops. 'module' is not a parameter of the lambda, so it is looked up in the enclosing scope each time the lambda is called. for loops leave their index (in this case, 'module') set at the final value, so that value is found in the globals, and used by each of the lambdas. To get what you were expecting, try api[module]=lambda x,module=module:module.callme(x) This binds the name 'module' (for that lambda) to whatever its current value is, at least as a default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390991&group_id=5470 From noreply at sourceforge.net Thu Dec 29 09:22:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 00:22:52 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 20:01 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-29 17:22 Message: Logged In: YES user_id=55188 The new patch tests it along with other locale-dependent tests on test__locale. How about this? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 04:00 Message: Logged In: YES user_id=38376 I'm not sure you can make too many assumptions about the locale in the test suite, but I'm pretty sure that it would be a good idea to let your "build robot" run the test suite twice; once with the standard C locale, and once with a non-US locale (e.g. sv_SE.utf8 which does include some odd characters, different date and money formats, and a decimal comma). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-29 03:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 23:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 22:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Thu Dec 29 16:32:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 07:32:57 -0800 Subject: [ python-Bugs-1392915 ] build fails on BSD 3.8 Message-ID: Bugs item #1392915, was opened at 2005-12-30 00: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=1392915&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on BSD 3.8 Initial Comment: There are several reports that python cannot be compiled in recent OpenBSD. The problem seems to be that configure script is not updated in sync with OpenBSD releases. Similar bug report can be found here:: www.python.org/sf/1026986 building on OpenBSD 3.5 Attached patch uses the same hack as this one. I didn't test it by myself, but the reporter said "it did the trick." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1392915&group_id=5470 From noreply at sourceforge.net Thu Dec 29 18:08:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 09:08:19 -0800 Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro Message-ID: Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-29 17:08 Message: Logged In: YES user_id=4771 Checked in as r41845. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:41 Message: Logged In: YES user_id=4771 I'm getting confused. First note that the problem I mentioned about extra_ivars() triggering an assert() can only occur at start-up. Indeed, PyType_Ready() copies the tp_base->tp_basicsize if the subtype's tp_basicsize is 0. So we can probably ignore the problem -- no extra_ivars() call would trigger the assert after start-up. The check that your patch adds is that solid_base(A) must be a superclass of solid_base(T) for each A in the mro of T. For built-in mros, the A's are exactly the superclasses of T. So we have to prove [*]: if A is a superclass of T, then solid_base(A) is a superclass of solid_base(T). Irrespective of what extra_ivars() does, solid_base(T) is either exactly T, or solid_base(T->tp_base). Moreover, when a type T is created with immediate bases B1...Bn, we check that all solid_bases of B1...Bn form a linear order (i.e. are subclasses of each other), and we set T->tp_base to the first Bi such that solid_base(Bi) is a subclass of all the other solid_base(Bj). Let's approach [*] above by induction on the set of types in which A and T are chosen. This set of types can be ordered by creation time: T1, T2, T3, ... where classes with a higher index can only inherit from classes with lower indices. Assume that [*] holds if A and T are chosen among T1...Tn-1. Let's prove it if A and/or T can also be Tn. The only non-trivial case is if A is a strict superclass of T=Tn. As above, let write B1...Bn for the immediate bases of T, with T->tp_base=Bi. Pick j such that A is a superclass of Bj. By induction solid_base(A) is a superclass of solid_base(Bj) which is a superclass of solid_base(Bi=T->tp_base). Now solid_base(T) is either T or solid_base(Bi). In both cases, solid_base(T) is a subclass of solid_base(A). This concludes the proof -- or I am missing something :-) In other words, I don't think the patch can break anything, so it should definitely go in. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-15 13:22 Message: Logged In: YES user_id=6656 Please see the attached PDF for a proof of ... well, something in the area. I think this is what typeobject.c should be doing and what it's *trying* to do. I'm less confident that this is what it's actually doing (particularly wrt the subclassing two subclasses of str thing). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-14 11:41 Message: Logged In: YES user_id=6656 Well, emprically that can't happen because the patch passes test_descr, and far sillier things happen in that file than in real life. More theoretically... I'll think about it :) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-03-14 11:25 Message: Logged In: YES user_id=4771 I tried to convince myself that this check always accepts the default mro, but there are more implicit assumptions around than I can handle in a quick review... Instead, I modified the patch so that a debug build of Python always does the check in mro_internal(). This results in a shallow problem: the basestring type has tp_basicsize==0, which makes the computation of its solid_base trigger an assertion in extra_ivars(). If I hack around this problem, then I cannot quickly find an example of built-in mro that triggers a TypeError, but it doesn't mean there isn't one... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-06 18:47 Message: Logged In: YES user_id=6656 I think the attached fixes all this. What it does: check the return value of PySequence_Tuple (duh). Check that the returned sequence contains only types or old-style classes. Checks that the solid_base of each type in the returned sequence is a supertype of the solid_base of type being built. Adds a few tests. The error messages are a bit inscrutable. I find it hard to care. Assigning to Armin for the first look. Might want to get Guido to look at it too. When Armin and I talked about this on IRC we found a few oddities in the general area, but I don't know if it's worth opening a new bug report for them... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-03 09:50 Message: Logged In: YES user_id=6656 Certainly some more checking of what the user-defined MRO contains would be good -- check the attached, which dumps core at class definition time... ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-03-03 09:34 Message: Logged In: YES user_id=4771 The PyXxx_Check() macros are #defined with PyObject_TypeCheck(). Should we change all these #defines to use a new PyObject_LayoutCheck() or something, and document to C extension writers that they should also switch to the new function? More generally, should we review *all* usages of PyObject_TypeCheck() and decide if they really meant that or PyObject_LayoutCheck()? Do we care about types that are solid subclasses of 'int' but don't have it in their MRO? Should we just forget the whole idea and sanity-check the user-defined mro, which after all would just add another strange undocumented condition to typeobject.c? :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-02 20:11 Message: Logged In: YES user_id=6656 Hmm, yeah, that works. It wasn't totally clear to me that the user couldn't maliciously influence tp_base, but I don't think they can... A helper function is presumably in order, unless PyType_IsSubtype should be changed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-03-02 17:03 Message: Logged In: YES user_id=4771 To solve the problem, as hinted in the title of this tracker, I think that PyXxx_Check() should simply not trust any mro. What PyInt_Check() really means at the C level is to check if an object memory layout is compatible with PyIntObject. This is easy to figure out by walking the "solid base" chain, tp_base. As a side note, PyPy gives the same error as Python 2.2. However, both in PyPy and in Python 2.2, you can still build an instance of the strange class X as follows: >>> x = object.__new__(X) Still, all the methods of x are resolved via the dict type. In PyPy we get a clean TypeError because the methods thus found don't apply to non-dict objects. In Python 2.2 you can crash the interpreter just as in more recent Python releases, e.g. with x[5]=6. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-01 20:18 Message: Logged In: YES user_id=6656 I wonder if Guido owes Armin a beer (read typeobject.c around line 5230). Well, not really, but it's that code that is making the difference. However, reversing the order of dict and object is sufficient to make 2.2 crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting code chopped out which gives the error jelper observes on the original). I wonder what to do about this. Removing the ability to customize the mro from user code is one obvious approach -- I don't know how much code uses this feature though. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-03-01 19:15 Message: Logged In: YES user_id=2772 Not sure if this is relevant, but the example given didn't crash 2.2: $ python2.2 bug.py Traceback (most recent call last): File "bug.py", line 9, in ? x = X() TypeError: dict.__new__(X) is not safe, use object.__new__() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 From noreply at sourceforge.net Thu Dec 29 19:52:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 10:52:56 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 12:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 19:52 Message: Logged In: YES user_id=38376 Looks good to me. I'll check this in shortly. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-29 09:22 Message: Logged In: YES user_id=55188 The new patch tests it along with other locale-dependent tests on test__locale. How about this? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:00 Message: Logged In: YES user_id=38376 I'm not sure you can make too many assumptions about the locale in the test suite, but I'm pretty sure that it would be a good idea to let your "build robot" run the test suite twice; once with the standard C locale, and once with a non-US locale (e.g. sv_SE.utf8 which does include some odd characters, different date and money formats, and a decimal comma). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-28 19:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 15:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 14:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 12:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Thu Dec 29 21:25:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 12:25:23 -0800 Subject: [ python-Bugs-1393109 ] cannot build SVN trunk on old systems Message-ID: Bugs item #1393109, was opened at 2005-12-29 21: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=1393109&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: cannot build SVN trunk on old systems Initial Comment: Parser/asdl_c.py uses "/usr/bin/env python" to find a proper python, but the script don't work on old Pythons (at least it fails on 2.1 and older). iirc, various solutions to this were discussed on python-dev, but nobody seems to have done anything about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 From noreply at sourceforge.net Thu Dec 29 21:37:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 12:37:44 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 12:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Neal Norwitz (nnorwitz) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:37 Message: Logged In: YES user_id=38376 Verified and fixed in SVN. Assinging to Neal, in case he wants to add an extra locale test pass to his build robot. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 19:52 Message: Logged In: YES user_id=38376 Looks good to me. I'll check this in shortly. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-29 09:22 Message: Logged In: YES user_id=55188 The new patch tests it along with other locale-dependent tests on test__locale. How about this? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:00 Message: Logged In: YES user_id=38376 I'm not sure you can make too many assumptions about the locale in the test suite, but I'm pretty sure that it would be a good idea to let your "build robot" run the test suite twice; once with the standard C locale, and once with a non-US locale (e.g. sv_SE.utf8 which does include some odd characters, different date and money formats, and a decimal comma). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-28 19:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 15:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 14:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 12:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Thu Dec 29 21:42:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 12:42:04 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-26 16:03 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: Nobody/Anonymous (nobody) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:42 Message: Logged In: YES user_id=38376 split isn't a word-wrapping split, so I'm not sure that's the right place to fix this. ("no-break space" is white- space, according to the Unicode standard, and split breaks on whitespace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Fri Dec 30 00:32:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 15:32:54 -0800 Subject: [ python-Bugs-1349732 ] urllib.urlencode provides two features in one param Message-ID: Bugs item #1349732, was opened at 2005-11-06 14:58 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349732&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlencode provides two features in one param Initial Comment: Using the 2.4 distribution. It seems that urlencode knows how to handle unicode input with quote_plus and ascii encoding, but it only does that when doseq is True. 1) There's no mention of that useful feature in the documentation. 2) If I want to encode unicode data without doseq's feature, there's no way to do so. Although it's rare to use doseq's intended function, they shouldn't be connected. Shouldn't values be checked with _is_unicode and handled correctly in both modes of doseq? One reason I see that *might* make the unicode check cause problems is the comment says "preserve old behavior" when doseq is False. Could such a check affect the behaviour of old code? If it can, the unicode handling could be another optional parameter. Also, the docstring is really unclear as to the purpose of doseq. Can an small example be added? (I saw no PEP guidelines for how examples should be given in docstrings, or if they're even allowed, so perhaps this fits just the regular documentation) With query={"key": ("val1", "val2") doseq=1 yields: key=val1&key=val2 doseq=0 yields: key=%28%27val1%27%2C+%27val2%27%29 After the correct solution is settled, I'll gladly submit a patch with the fixes. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2005-12-29 16:32 Message: Logged In: YES user_id=371366 I understand why the implementation is the way it is. I agree that it is not documented as ideally as it could be. I also agree with your implication that ASCII-range unicode input should be acceptable (and converted to ASCII bytes internally before percent-encoding), regardless of doseq. I would not go so far as to say non-ASCII-range unicode should be accepted, since safe conversion to bytes before percent-encoding would not be possible. However, I was unable to reproduce your observation that doseq=0 results in urlencode not knowing how to handle unicode. The object is just passed to str(). Granted, that's not *quite* the same as when doseq=1, where unicode objects are specifically run through .encode('us-ascii','replace')), but I wouldn't characterize it as not knowing how to handle ASCII-range unicode. The results for ASCII-range unicode are the same. If you're going to make things more consistent, I would actually tighten up the doseq=1 behavior, replacing v = quote_plus(v.encode("ASCII","replace")) with v = quote_plus(v.encode("ASCII","strict")) and then mention in the docs that any object type is acceptable as a key or value, but if unicode is passed, it must be all ASCII-range characters; if there is a risk of characters above \u007f being passed, then the caller should convert the unicode to str beforehand. As for doseq's purpose and documentation, the doseq=1 behavior is ideal for almost all situations, since it takes care not to treat str or unicode as a sequence of separate 1-character values. AFAIK, the only reason it isn't the default is for backward compatiblity. It was introduced in Python 2.0.1 and was trying to retain compatibility with code written for Python 1.5.2 through 2.0.0. I suggest deprecating it and making doseq=1 behavior the default, if others (MvL?) approve. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349732&group_id=5470 From noreply at sourceforge.net Fri Dec 30 01:30:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 16:30:45 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-27 00:03 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: Nobody/Anonymous (nobody) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-30 09:30 Message: Logged In: YES user_id=55188 Python documentation says that it splits in "whitespace characters" not "breaking characters". So, current behavior is correct according to the documentation. And even rationale among string methods are heavily depends on ctype functions on libc. Therefore, we can't serve special treatment for the NBSP. However, I feel the need for the splitting function that awares what character is breaking or not. How about to add it as unicodedata.split()? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-30 05:42 Message: Logged In: YES user_id=38376 split isn't a word-wrapping split, so I'm not sure that's the right place to fix this. ("no-break space" is white- space, according to the Unicode standard, and split breaks on whitespace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Fri Dec 30 08:06:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 23:06:47 -0800 Subject: [ python-Bugs-1384175 ] random module - Provider DLL failed to initialize correctly Message-ID: Bugs item #1384175, was opened at 2005-12-18 01:18 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: random module - Provider DLL failed to initialize correctly Initial Comment: File "random.pyc", line 828, in ? File "random.pyc", line 95, in __init__ File "random.pyc", line 109, in seed WindowsError: [Errno -2146893795] Provider DLL failed to initialize correctly ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2005-12-30 07:06 Message: Logged In: YES user_id=731668 Windows XP, python 2.4.2 Not sure how to reproduce it. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-18 11:00 Message: Logged In: YES user_id=1188172 Could you provide some more information? OS specs, Python version, reproducability etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470 From noreply at sourceforge.net Fri Dec 30 13:35:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Dec 2005 04:35:01 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-26 16:03 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: Nobody/Anonymous (nobody) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-12-30 13:35 Message: Logged In: YES user_id=89016 What's wrong with the following? import sys, unicodedata spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) foo.split(spaces) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-30 01:30 Message: Logged In: YES user_id=55188 Python documentation says that it splits in "whitespace characters" not "breaking characters". So, current behavior is correct according to the documentation. And even rationale among string methods are heavily depends on ctype functions on libc. Therefore, we can't serve special treatment for the NBSP. However, I feel the need for the splitting function that awares what character is breaking or not. How about to add it as unicodedata.split()? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:42 Message: Logged In: YES user_id=38376 split isn't a word-wrapping split, so I'm not sure that's the right place to fix this. ("no-break space" is white- space, according to the Unicode standard, and split breaks on whitespace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Fri Dec 30 14:06:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Dec 2005 05:06:23 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-26 16:03 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: MvR (maxim_razin) >Assigned to: M.-A. Lemburg (lemburg) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-30 14:06 Message: Logged In: YES user_id=38388 Maxim, you are right that \xA0 is a non-break space. However, like the others already mentioned, the .split() method defaults to breaking a string on whitespace characters, not breakable whitespace characters. The intent is not a typographical one, but originates from the desire to quickly tokenize a string. If you'd rather like to see a different set of whitespace characters used, you can pass such a template string to the .split() method (Walter gave an example). Closing this as "Won't fix". ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-30 13:35 Message: Logged In: YES user_id=89016 What's wrong with the following? import sys, unicodedata spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) foo.split(spaces) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-30 01:30 Message: Logged In: YES user_id=55188 Python documentation says that it splits in "whitespace characters" not "breaking characters". So, current behavior is correct according to the documentation. And even rationale among string methods are heavily depends on ctype functions on libc. Therefore, we can't serve special treatment for the NBSP. However, I feel the need for the splitting function that awares what character is breaking or not. How about to add it as unicodedata.split()? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:42 Message: Logged In: YES user_id=38376 split isn't a word-wrapping split, so I'm not sure that's the right place to fix this. ("no-break space" is white- space, according to the Unicode standard, and split breaks on whitespace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Fri Dec 30 17:10:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Dec 2005 08:10:55 -0800 Subject: [ python-Bugs-1349732 ] urllib.urlencode provides two features in one param Message-ID: Bugs item #1349732, was opened at 2005-11-06 23:58 Message generated for change (Comment added) made by salty-horse You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349732&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlencode provides two features in one param Initial Comment: Using the 2.4 distribution. It seems that urlencode knows how to handle unicode input with quote_plus and ascii encoding, but it only does that when doseq is True. 1) There's no mention of that useful feature in the documentation. 2) If I want to encode unicode data without doseq's feature, there's no way to do so. Although it's rare to use doseq's intended function, they shouldn't be connected. Shouldn't values be checked with _is_unicode and handled correctly in both modes of doseq? One reason I see that *might* make the unicode check cause problems is the comment says "preserve old behavior" when doseq is False. Could such a check affect the behaviour of old code? If it can, the unicode handling could be another optional parameter. Also, the docstring is really unclear as to the purpose of doseq. Can an small example be added? (I saw no PEP guidelines for how examples should be given in docstrings, or if they're even allowed, so perhaps this fits just the regular documentation) With query={"key": ("val1", "val2") doseq=1 yields: key=val1&key=val2 doseq=0 yields: key=%28%27val1%27%2C+%27val2%27%29 After the correct solution is settled, I'll gladly submit a patch with the fixes. ---------------------------------------------------------------------- >Comment By: Ori Avtalion (salty-horse) Date: 2005-12-30 18:10 Message: Logged In: YES user_id=854801 > However, I was unable to reproduce your observation that > doseq=0 results in urlencode not knowing how to handle > unicode. I had given urlencode a hebrew unicode string, and "".encode() could not convert it to ascii: s_unicode = u'\u05d1\u05d3\u05d9\u05e7\u05d4' print urllib.urlencode({"key":s_unicode}, 0) As I notice now, the line: >> urllib.urlencode({"key":s_unicode}, 1) key=%3F%3F%3F%3F%3F does not raise an exception but produces an incorrect result. The correct way to call it is like this: >> urllib.urlencode({"key":s_unicode.encode("iso8859_8")}, 1) key=%E1%E3%E9%F7%E4 So, in addition to your suggestion, I think the documentation should explicitly state that unicode strings will be treated as us-ascii. What about my suggestion of an example for doseq's behaviour in the docstring? ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2005-12-30 01:32 Message: Logged In: YES user_id=371366 I understand why the implementation is the way it is. I agree that it is not documented as ideally as it could be. I also agree with your implication that ASCII-range unicode input should be acceptable (and converted to ASCII bytes internally before percent-encoding), regardless of doseq. I would not go so far as to say non-ASCII-range unicode should be accepted, since safe conversion to bytes before percent-encoding would not be possible. However, I was unable to reproduce your observation that doseq=0 results in urlencode not knowing how to handle unicode. The object is just passed to str(). Granted, that's not *quite* the same as when doseq=1, where unicode objects are specifically run through .encode('us-ascii','replace')), but I wouldn't characterize it as not knowing how to handle ASCII-range unicode. The results for ASCII-range unicode are the same. If you're going to make things more consistent, I would actually tighten up the doseq=1 behavior, replacing v = quote_plus(v.encode("ASCII","replace")) with v = quote_plus(v.encode("ASCII","strict")) and then mention in the docs that any object type is acceptable as a key or value, but if unicode is passed, it must be all ASCII-range characters; if there is a risk of characters above \u007f being passed, then the caller should convert the unicode to str beforehand. As for doseq's purpose and documentation, the doseq=1 behavior is ideal for almost all situations, since it takes care not to treat str or unicode as a sequence of separate 1-character values. AFAIK, the only reason it isn't the default is for backward compatiblity. It was introduced in Python 2.0.1 and was trying to retain compatibility with code written for Python 1.5.2 through 2.0.0. I suggest deprecating it and making doseq=1 behavior the default, if others (MvL?) approve. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349732&group_id=5470 From noreply at sourceforge.net Sat Dec 31 05:24:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Dec 2005 20:24:52 -0800 Subject: [ python-Bugs-1394135 ] Deleting first item causes anydbm.first() to fail Message-ID: Bugs item #1394135, was opened at 2005-12-30 20: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=1394135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dan Bisalputra (danbiz) Assigned to: Nobody/Anonymous (nobody) Summary: Deleting first item causes anydbm.first() to fail Initial Comment: If the first item in a database is deleted, the first call to anydbm.first() after the deletion causes a DBNotFoundError exception to be raised. The attached program causes the error on my system. I am currently working around the problem by calling first() after each deletion, enclosed by a try block. I am using Python 2.4.2 running under Windows ME. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 From noreply at sourceforge.net Sat Dec 31 17:46:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Dec 2005 08:46:15 -0800 Subject: [ python-Bugs-1394453 ] urllib2 raises exception when page redirects to itself Message-ID: Bugs item #1394453, was opened at 2005-12-31 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=1394453&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ren?? Pijlman (rpijlman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 raises exception when page redirects to itself Initial Comment: Some sites redirect a page to itself, due to a configuration error or bug. The popular browsers seem to be forgiving: when a URL redirects to itself, they break the infinite redirect loop and simply display the page (verified in IE6 and Firefox 1.5). urllib2.urlopen() raises an exception in the same situation: HTTP Error 302: The HTTP server returned a redirect error that would lead to an infinite loop. Although this message is technically correct, I think the situation of a page redirecting to itself should be handled as a special case. It should abort the redirect and continue with the current request. Users expect urllib to be able to access sites that popular browsers can apparently access without problems. To reproduce (pick a site with this redirect anomaly): import urllib2 try: handle = urllib2.urlopen('http://www.haselhoff.nl/default.asp') except IOError,e: print str(e) Reproduced with Python 2.3.5 on Windows XP and Linux. Also with today's trunk (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394453&group_id=5470 From noreply at sourceforge.net Sat Dec 31 19:10:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Dec 2005 10:10:31 -0800 Subject: [ python-Bugs-1394453 ] urllib2 raises exception when page redirects to itself Message-ID: Bugs item #1394453, was opened at 2005-12-31 17:46 Message generated for change (Comment added) made by rpijlman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394453&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ren?? Pijlman (rpijlman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 raises exception when page redirects to itself Initial Comment: Some sites redirect a page to itself, due to a configuration error or bug. The popular browsers seem to be forgiving: when a URL redirects to itself, they break the infinite redirect loop and simply display the page (verified in IE6 and Firefox 1.5). urllib2.urlopen() raises an exception in the same situation: HTTP Error 302: The HTTP server returned a redirect error that would lead to an infinite loop. Although this message is technically correct, I think the situation of a page redirecting to itself should be handled as a special case. It should abort the redirect and continue with the current request. Users expect urllib to be able to access sites that popular browsers can apparently access without problems. To reproduce (pick a site with this redirect anomaly): import urllib2 try: handle = urllib2.urlopen('http://www.haselhoff.nl/default.asp') except IOError,e: print str(e) Reproduced with Python 2.3.5 on Windows XP and Linux. Also with today's trunk (2.5). ---------------------------------------------------------------------- >Comment By: Ren?? Pijlman (rpijlman) Date: 2005-12-31 19:10 Message: Logged In: YES user_id=1416482 Forget it. I misunderstood. The reason some sites redirect to the current page itself, is to first set a cookie. I retried with cookie support in urllib2 and cookielib in Python 2.4. With HTTPCookieProcessor installed as opener urllib2.urlopen worked fine on two different sites that showed this 'problem'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394453&group_id=5470 From noreply at sourceforge.net Sat Dec 31 19:10:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Dec 2005 10:10:51 -0800 Subject: [ python-Bugs-1394453 ] urllib2 raises exception when page redirects to itself Message-ID: Bugs item #1394453, was opened at 2005-12-31 17:46 Message generated for change (Settings changed) made by rpijlman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394453&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Ren?? Pijlman (rpijlman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 raises exception when page redirects to itself Initial Comment: Some sites redirect a page to itself, due to a configuration error or bug. The popular browsers seem to be forgiving: when a URL redirects to itself, they break the infinite redirect loop and simply display the page (verified in IE6 and Firefox 1.5). urllib2.urlopen() raises an exception in the same situation: HTTP Error 302: The HTTP server returned a redirect error that would lead to an infinite loop. Although this message is technically correct, I think the situation of a page redirecting to itself should be handled as a special case. It should abort the redirect and continue with the current request. Users expect urllib to be able to access sites that popular browsers can apparently access without problems. To reproduce (pick a site with this redirect anomaly): import urllib2 try: handle = urllib2.urlopen('http://www.haselhoff.nl/default.asp') except IOError,e: print str(e) Reproduced with Python 2.3.5 on Windows XP and Linux. Also with today's trunk (2.5). ---------------------------------------------------------------------- Comment By: Ren?? Pijlman (rpijlman) Date: 2005-12-31 19:10 Message: Logged In: YES user_id=1416482 Forget it. I misunderstood. The reason some sites redirect to the current page itself, is to first set a cookie. I retried with cookie support in urllib2 and cookielib in Python 2.4. With HTTPCookieProcessor installed as opener urllib2.urlopen worked fine on two different sites that showed this 'problem'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394453&group_id=5470 From noreply at sourceforge.net Sat Dec 31 22:46:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Dec 2005 13:46:44 -0800 Subject: [ python-Bugs-1394565 ] SimpleHTTPServer doesn't understand query arguments Message-ID: Bugs item #1394565, was opened at 2005-12-31 15: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=1394565&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer doesn't understand query arguments Initial Comment: If you set the SimpleHTTPServer to serve files and visit /filename it works but if you visit /filename?f=1 it returns a 404. It should strip off the query argument and visit /filename ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394565&group_id=5470