From noreply at sourceforge.net Fri Jul 1 18:24:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jul 2005 09:24:38 -0700 Subject: [ python-Bugs-1231069 ] ioctl has problem with -ive request codes Message-ID: Bugs item #1231069, was opened at 2005-07-01 17: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=1231069&group_id=5470 Please note that this 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: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: ioctl has problem with -ive request codes Initial Comment: On Linux many ioctl request code values cannot be passed to ioctl because it assumes that the values are signed ints. Value with the top bit set 0x8000000 are common. Changing the PyArg_ParseTuple calls to use "I" instead of "i" fixes the problem. This may well also be the issue with bug 1112949 "ioctl has problems on 64 bit machines". The attached patch fixes the problem in 2.4.1 and was tested on FC4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 From noreply at sourceforge.net Fri Jul 1 18:38:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jul 2005 09:38:26 -0700 Subject: [ python-Feature Requests-1231081 ] platform.processor() could be smarter Message-ID: Feature Requests item #1231081, was opened at 2005-07-01 18:38 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=1231081&group_id=5470 Please note that this 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: Stephan Springer (tengai) Assigned to: Nobody/Anonymous (nobody) Summary: platform.processor() could be smarter Initial Comment: As far as I can see, platform.py only looks at the output of "uname -p" when platform.processor() is called. But on my system (Debian Linux), this doesn't give a result. Could you please enhance this function in a way that it also looks at /proc/cpuinfo? I'd need this to automatically find the appropriate options like "-march=..." and "-msse" for gcc/g++ in an scons script. Thanks, - Stephan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1231081&group_id=5470 From noreply at sourceforge.net Fri Jul 1 19:22:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jul 2005 10:22:23 -0700 Subject: [ python-Bugs-1028088 ] Cookies without values are silently ignored (by design?) Message-ID: Bugs item #1028088, was opened at 2004-09-14 19:05 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470 Please note that this message 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: Doug Sheppard (sirilyan) Assigned to: A.M. Kuchling (akuchling) Summary: Cookies without values are silently ignored (by design?) Initial Comment: Cookie._CookiePattern is the regular expression used to retrieve cookies from the HTTP_COOKIE environment variable. This pattern assumes that all cookies are in "name=value" format. A cookie that doesn't have an "=value" component is silently skipped over. (It's easy to generate a cookie like that - in JavaScript, document.cookie="broken" is all it takes.) >>> import Cookie >>> q = Cookie.SimpleCookie("pie=good; broken; other=thing") >>> q If ignoring cookies without a "=value" component is intended behaviour, it'd be nice to have a code comment warning that's what happens. If it's a bug, the cookie should be set with an empty value. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-07-01 18:22 Message: Logged In: YES user_id=261020 In the last sentence of my previous comment, I meant to say: "if the latter". ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-06-29 21:02 Message: Logged In: YES user_id=261020 Though I had previously assumed stability is more important than the precise details of what module Cookie does (since you can choose what cookies you send, the only important thing is that behaviour is relatively sane, and does the job -- in a standards-compliant way -- with browsers). But I suppose one can have JS code or other web app code maintained by others, and have to understand cookies that were emitted by that code. Is that your situation? Do 'serious' web developers use module Cookie, or do people now tend to use web frameworks' own cookie code (personally I don't use cookies in my web application work). If the former, perhaps we should not tinker with this module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470 From noreply at sourceforge.net Sat Jul 2 05:13:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jul 2005 20:13:05 -0700 Subject: [ python-Bugs-1229788 ] Bus error in extension with gcc 3.3 Message-ID: Bugs item #1229788, was opened at 2005-06-29 11:43 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Robinson (garyrob) Assigned to: Nobody/Anonymous (nobody) Summary: Bus error in extension with gcc 3.3 Initial Comment: This text contains a c module with 4 versions of the same extremely simple function. All they do is return a float double to python. On Windows I have received a report from someone who can built the module, imported it into Python, and ran it successfully. It has also been reported that there is no problem when the extension is compiled with gcc 4.0 on OS X. However, on OS X, if the extension is compiled with gcc 3.3, the 4th of the 4 function results in a bus error: >>> from check import * fun0() 411.0 >>> fun1() 534.30000000000007 >>> fun2() 411.0 >>> fun3() Bus error I originally reported this on the C++ sig's mail list. They suggested I try dev-python. Scott David Daniels on that list helped me refine some test cases and verified that they all worked on Windows. Along the way it was suggested that I post a bug report. So this is it. The code follows: #include "Python.h" static double value = 411.0; static PyObject * fun0(PyObject *self, PyObject *args) { if (!PyArg_ParseTuple(args, "", NULL)) return NULL; return Py_BuildValue("d", value); } static PyObject * fun1(PyObject *self, PyObject *args) { return Py_BuildValue("d", 1.3*value); } static PyObject * fun2(PyObject *self, PyObject *args) { return PyFloat_FromDouble(value); } static PyObject * fun3(PyObject *self, PyObject *args) { return Py_BuildValue("d", value); } static PyMethodDef TestMethods[] = { {"fun0", fun0, METH_VARARGS, "Read args and return value"}, {"fun1", fun1, METH_VARARGS, "Return value multiplied inline by 1.3"}, {"fun2", fun2, METH_VARARGS, "Return value using PyFloat_FromDouble"}, {"fun3", fun3, METH_VARARGS, "Return value using Py_BuildValue without reading args -- causes bus error on OS X Panther with XCode 1.5 installed"}, {NULL, NULL, 0, NULL} /* Sentinel */ }; PyMODINIT_FUNC initcheck(void) { PyObject *module; module = Py_InitModule3("check", TestMethods, "extension module with three functions."); if (module) { PyModule_AddStringConstant(module, "__version__", "0.02"); } } ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-07-01 23:13 Message: Logged In: YES user_id=593130 I understand that you got advice to post, but I strongly doubt that core Python code is involved for three reasons. 1. On the Unix I used, bus errors were much rarer and esoteric than segmentation violations (from bad pointers). But maybe BSD-derived OSX is different. 2. The only difference between fun1 that works and fun3 that doesn't, seems to be how the arg in computed. The receiving function only gets a value (which it copies) and does not know its history. 3. You report that upgrading the compiler fixes the problem. (So why not just do that?) If you want to experiment more, redo fun1 and fun3 with 'value' replaced by its literal value. Then redo again with value = 534.30000000000007 instead of 411 and change arg in fun1 to value/1.3 instead of 1.3*value. About stack trace: On unix (of 15 years ago), program crashes usually resulted in a file called 'core' added to either the startup or current working directory. A debugger program could extract a stack trace, which was more readable if the executable still had the symbol table attached and not stripped. I don't know equivalent for OSX, but I found it very helpful for debugging. ---------------------------------------------------------------------- Comment By: Gary Robinson (garyrob) Date: 2005-06-30 16:15 Message: Logged In: YES user_id=136420 It was reproduced by someone with Python 2.4 and gcc 3.3. So it is not my machine. As to closing it, a couple of people in the python C++ sig and python-dev suggested I post it here as a bug, so I did. I'm just doing what was requested of me. I don't mind if someone else feels it should be closed without doing anything about it, but I don't think everyone would agree with that action. As for stack trace, I don't know how to look for that. All I got was the "bus error" message. If you tell me what to look for I'll look for it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-06-30 16:05 Message: Logged In: YES user_id=593130 Do you have any reason to think the bug is in Python rather than the older version of gcc? Or OSX? Or even your computer? If not, please consider closing. Does OSX give you a stack trace? If so,what is executing when the crash occurs? In fun3, Py_BuildValue, or somehow inbewteen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470 From noreply at sourceforge.net Sat Jul 2 12:29:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 03:29:18 -0700 Subject: [ python-Bugs-1168746 ] frame.f_exc_type,value,traceback Message-ID: Bugs item #1168746, was opened at 2005-03-23 00:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&group_id=5470 Please note that this 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: 4 Submitted By: Armin Rigo (arigo) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: frame.f_exc_type,value,traceback Initial Comment: The frame object attributes f_exc_type, f_exc_value, f_exc_traceback are misdocumented. They are not the last exception caught by the frame, nor the one currently handled, or anything reasonable like that. They give the last exception raised in the parent frame, and only if another exception was ever raised in the current frame (in all other cases they are None). I very much doubt this is useful to anyone, so maybe un-publishing the attributes would be sensible, but in any case the doc needs a small fix (ref/types.html and the doc about and in inspect.py). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:29 Message: Logged In: YES user_id=1188172 Okay, checked in patch #1230615 as Doc/ref/ref3.tex r1.125, r1.121.2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&group_id=5470 From noreply at sourceforge.net Sat Jul 2 12:30:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 03:30:38 -0700 Subject: [ python-Bugs-1204734 ] __getattribute__ documentation error? Message-ID: Bugs item #1204734, was opened at 2005-05-19 07:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 Please note that this 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: John Eikenberry (zhar) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: __getattribute__ documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:30 Message: Logged In: YES user_id=1188172 Checked in my patch as Doc/ref/ref3.tex r1.125, r1.121.2.4. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:03 Message: Logged In: YES user_id=1188172 Attached a documentation patch, following Terry's wording. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 19:42 Message: Logged In: YES user_id=593130 If I understand correctly, this revision of the consequent of the second sentence (after ',') matches the implementation. [If the class also defines __getattr__, ] the latter will not be called unless __getattribute__ either calls it explicitly or raises an AttributeError. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-05-26 18:18 Message: Logged In: YES user_id=6380 The implementation works as expected. The documentation is flawed. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-26 17:52 Message: Logged In: YES user_id=322022 Terry, I started with a much longer subject but decided I didn't want to overload it to much. Guess I went to far the other way. I'll try to strike a better balance next time. Thanks. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 17:43 Message: Logged In: YES user_id=593130 John E: A general title like 'Documentation Error?' discourages attention from people with the specialized knowledge needed to answer such a question. I have taken the liberty of trying to add '__getattribute__'. We'll see if the edit works when I, not the OP, submits it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 17:33 Message: Logged In: YES user_id=593130 If the default __getattribute__ explicitly calls __getattr__ (but I don't know which source file to check), then the second sentence above *would* make some sense. Guido (or deputy): what is your design intention? Note: if the second sentence is kept, replacing 'it' with 'the latter' would make it clearer. I first read 'it' as referring to __getattribute__. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-24 11:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-23 20:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make explicit if you can write code relying on this 'feature' and not have it break at some point. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 16:28 Message: Logged In: YES user_id=4771 Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError. This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class. This let me think that the error is really in the documentation, which should mention this logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 From noreply at sourceforge.net Sat Jul 2 12:45:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 03:45:09 -0700 Subject: [ python-Bugs-1228904 ] weakref example broken Message-ID: Bugs item #1228904, was opened at 2005-06-28 12:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470 Please note that this 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: paolo veronelli (paolo_veronelli) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: weakref example broken Initial Comment: Surely the example in python2.4/lib/weakref-objects.html is untested .Bad story. Attached a working version which I suppose correct it . ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:45 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libweakref.py r1.28, r1.27.4.1. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-29 21:46 Message: Logged In: YES user_id=174455 I can confirm this (in 2.5a0). It seems untested as it contains several small errors. I have submitted a doc-patch with working code that is also a simplified version. See patch #1229935. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470 From noreply at sourceforge.net Sat Jul 2 12:50:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 03:50:40 -0700 Subject: [ python-Bugs-1229646 ] httplib error checking. Message-ID: Bugs item #1229646, was opened at 2005-06-29 13:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: httplib error checking. Initial Comment: The httplib does not seem to handle error codes cleanly or in a portable way. The socket could return a ECONNRESET and does on the RTEMS platform. Also value 32 is normally EPIPE, but ECONNRESET is different so the Python errno should be used. [please excuse the manual diff :-)] line 657: < if v[0] == 32: # Broken pipe line 657: > if v[0] == errno.EPIPE or v[0] == errno.ECONNRESET: line 803: > if v[0] != 32 or not self.auto_open: line 803: > if (v[0] != errno.EPIPE and v[0] != errno.ECONNRESET) or not self.auto_open: I can provide a patch if this change make sense. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:50 Message: Logged In: YES user_id=1188172 Can someone judge if this makes sense? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229646&group_id=5470 From noreply at sourceforge.net Sat Jul 2 15:52:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 06:52:28 -0700 Subject: [ python-Bugs-1231488 ] chr() returns ? when input > 127 in OS X Message-ID: Bugs item #1231488, was opened at 2005-07-02 09:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231488&group_id=5470 Please note that this 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: Craig Howard (craighoward) Assigned to: Nobody/Anonymous (nobody) Summary: chr() returns ? when input > 127 in OS X Initial Comment: When using macpython in OS X Tiger, chr(130) should return an "e" with an accent symbol above it. Instead it returns a "?", as it does with any number above 127. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231488&group_id=5470 From noreply at sourceforge.net Sat Jul 2 19:49:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jul 2005 10:49:49 -0700 Subject: [ python-Bugs-1228904 ] weakref example broken Message-ID: Bugs item #1228904, was opened at 2005-06-28 05:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470 Please note that this 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: paolo veronelli (paolo_veronelli) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: weakref example broken Initial Comment: Surely the example in python2.4/lib/weakref-objects.html is untested .Bad story. Attached a working version which I suppose correct it . ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-02 12:49 Message: Logged In: YES user_id=80475 It would be useful to add a testcase cover the examples in the docs. See test_itertools.py for an example of how that is done. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 05:45 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libweakref.py r1.28, r1.27.4.1. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-29 14:46 Message: Logged In: YES user_id=174455 I can confirm this (in 2.5a0). It seems untested as it contains several small errors. I have submitted a doc-patch with working code that is also a simplified version. See patch #1229935. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470 From noreply at sourceforge.net Sun Jul 3 16:50:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jul 2005 07:50:26 -0700 Subject: [ python-Bugs-1231069 ] ioctl has problem with -ive request codes Message-ID: Bugs item #1231069, was opened at 2005-07-01 17:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 Please note that this 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: Barry Alan Scott (barry-scott) >Assigned to: Michael Hudson (mwh) Summary: ioctl has problem with -ive request codes Initial Comment: On Linux many ioctl request code values cannot be passed to ioctl because it assumes that the values are signed ints. Value with the top bit set 0x8000000 are common. Changing the PyArg_ParseTuple calls to use "I" instead of "i" fixes the problem. This may well also be the issue with bug 1112949 "ioctl has problems on 64 bit machines". The attached patch fixes the problem in 2.4.1 and was tested on FC4. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-03 15:50 Message: Logged In: YES user_id=6656 The patch seems to be empty (!?) Good idea, although not goo enough for me to fight CVS over dialup... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 From noreply at sourceforge.net Sun Jul 3 17:01:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jul 2005 08:01:47 -0700 Subject: [ python-Bugs-1231488 ] chr() returns ? when input > 127 in OS X Message-ID: Bugs item #1231488, was opened at 2005-07-02 14:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231488&group_id=5470 Please note that this 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: Craig Howard (craighoward) Assigned to: Nobody/Anonymous (nobody) Summary: chr() returns ? when input > 127 in OS X Initial Comment: When using macpython in OS X Tiger, chr(130) should return an "e" with an accent symbol above it. Instead it returns a "?", as it does with any number above 127. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-03 16:01 Message: Logged In: YES user_id=6656 I have a hard time believing this report at face value. How are you determining that chr(130) is "?"? Are you sure that it's not just being *printed* that way? Also, I don't see why you think chr(130) should be LATIN SMALL LETTER E WITH ACUTE. That character is 142 in the mac roman encoding and 233 in the latin-1/iso8859-1 encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231488&group_id=5470 From noreply at sourceforge.net Sun Jul 3 22:00:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jul 2005 13:00:03 -0700 Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage Message-ID: Bugs item #1162912, was opened at 2005-03-14 12:20 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 Please note that this 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: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-03 22:00 Message: Logged In: YES user_id=174455 I have submittted a doc patch (#1231890) that adds a note that reads: If both key and cmp are supplied the key function is applied before the cmp function. (You can check listsort in listobject.c to verify) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 From noreply at sourceforge.net Sun Jul 3 22:22:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jul 2005 13:22:27 -0700 Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage Message-ID: Bugs item #1162912, was opened at 2005-03-14 12:20 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 Please note that this 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: Stefan Behnel (scoder) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-03 22:22 Message: Logged In: YES user_id=1188172 Thanks for the report and the patch. Committed as Doc/lib/libstdtypes.tex r1.183, r1.170.2.12. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-03 22:00 Message: Logged In: YES user_id=174455 I have submittted a doc patch (#1231890) that adds a note that reads: If both key and cmp are supplied the key function is applied before the cmp function. (You can check listsort in listobject.c to verify) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 From noreply at sourceforge.net Mon Jul 4 06:13:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jul 2005 21:13:40 -0700 Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage Message-ID: Bugs item #1162912, was opened at 2005-03-14 06:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 Please note that this 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: Stefan Behnel (scoder) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-03 23:13 Message: Logged In: YES user_id=80475 Actually, it should NOT be documented because 1) it is an implementation specific detail and 2) using key and cmp together is almost always the wrong thing to do. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-03 15:22 Message: Logged In: YES user_id=1188172 Thanks for the report and the patch. Committed as Doc/lib/libstdtypes.tex r1.183, r1.170.2.12. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-03 15:00 Message: Logged In: YES user_id=174455 I have submittted a doc patch (#1231890) that adds a note that reads: If both key and cmp are supplied the key function is applied before the cmp function. (You can check listsort in listobject.c to verify) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 From noreply at sourceforge.net Mon Jul 4 10:21:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 01:21:58 -0700 Subject: [ python-Feature Requests-1231081 ] platform.processor() could be smarter Message-ID: Feature Requests item #1231081, was opened at 2005-07-01 16:38 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1231081&group_id=5470 Please note that this 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: Stephan Springer (tengai) Assigned to: Nobody/Anonymous (nobody) Summary: platform.processor() could be smarter Initial Comment: As far as I can see, platform.py only looks at the output of "uname -p" when platform.processor() is called. But on my system (Debian Linux), this doesn't give a result. Could you please enhance this function in a way that it also looks at /proc/cpuinfo? I'd need this to automatically find the appropriate options like "-march=..." and "-msse" for gcc/g++ in an scons script. Thanks, - Stephan. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-07-04 08:21 Message: Logged In: YES user_id=987664 This sounds like it would be an endless sink of new code to deal with various processors and /proc formats on different platforms. If uname -p doesn't give you a result on Debian, that sounds like a Debian bug that should be taken up with them. I presume you want something like this: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.66GHz stepping : 7 cpu MHz : 2660.595 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 5275.64 to be transformed into the str "pentium4"? I think this RFE should be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1231081&group_id=5470 From noreply at sourceforge.net Mon Jul 4 10:25:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 01:25:17 -0700 Subject: [ python-Feature Requests-1226256 ] Add Jason Orendorff's path module to stdlib Message-ID: Feature Requests item #1226256, was opened at 2005-06-23 13:26 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1226256&group_id=5470 Please note that this message 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: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add Jason Orendorff's path module to stdlib Initial Comment: Jason Orendorff has produced an excellent path module which has an OOP approach to path, directory, and file manipulation, as well as including some new convenience functions. In my opinion, it allows much more Pythonic path manipulation than the functions in os and os.path. It is quite stable and includes unit tests. I and many others have been using it for years. http://www.jorendorff.com/articles/python/path/ I am requesting that it be added to the stdlib. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2005-07-04 08:25 Message: Logged In: YES user_id=987664 Significant discussion on python-dev in this thread: http://mail.python.org/pipermail/python-dev/2005-June/054438.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1226256&group_id=5470 From noreply at sourceforge.net Mon Jul 4 10:28:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 01:28:32 -0700 Subject: [ python-Feature Requests-1232073 ] Links to tutorials and howtos from references Message-ID: Feature Requests item #1232073, was opened at 2005-07-04 08:28 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=1232073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Links to tutorials and howtos from references Initial Comment: I see many people on comp.lang.python who are frustrated by the existing documentation, which is written at an advanced level for total beginners. It might aid in discoverability of the tutorial and howtos if more "See also" links were placed in language and library reference pages. For example: could link to . This would probably reduce the number of basic re questions on c.l.p and tutor, and make it easier to learn the language and stdlib. I'll submit my own patches as I have time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1232073&group_id=5470 From noreply at sourceforge.net Mon Jul 4 11:52:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 02:52:22 -0700 Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage Message-ID: Bugs item #1162912, was opened at 2005-03-14 12:20 Message generated for change (Comment added) made by scoder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 Please note that this 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: Stefan Behnel (scoder) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. ---------------------------------------------------------------------- >Comment By: Stefan Behnel (scoder) Date: 2005-07-04 11:52 Message: Logged In: YES user_id=313935 ... except, for example, when implementing classes that behave like builtins and stdlib. So, if it's an implementation detail, why not document that and give the hint that the current CPython implementation applies key before cmp? I do not think it matters that using them together is "almost always the wrong thing to do". In that case, it should either become impossible or at least merit an understandable warning in the documentation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 06:13 Message: Logged In: YES user_id=80475 Actually, it should NOT be documented because 1) it is an implementation specific detail and 2) using key and cmp together is almost always the wrong thing to do. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-03 22:22 Message: Logged In: YES user_id=1188172 Thanks for the report and the patch. Committed as Doc/lib/libstdtypes.tex r1.183, r1.170.2.12. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-03 22:00 Message: Logged In: YES user_id=174455 I have submittted a doc patch (#1231890) that adds a note that reads: If both key and cmp are supplied the key function is applied before the cmp function. (You can check listsort in listobject.c to verify) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 From noreply at sourceforge.net Mon Jul 4 12:21:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 03:21:07 -0700 Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage Message-ID: Bugs item #1162912, was opened at 2005-03-14 12:20 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 Please note that this 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: Stefan Behnel (scoder) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 12:21 Message: Logged In: YES user_id=1188172 But in this case, don't you think that the implementor would in every case look up how it's done in the source code? Raymond, please decide. ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2005-07-04 11:52 Message: Logged In: YES user_id=313935 ... except, for example, when implementing classes that behave like builtins and stdlib. So, if it's an implementation detail, why not document that and give the hint that the current CPython implementation applies key before cmp? I do not think it matters that using them together is "almost always the wrong thing to do". In that case, it should either become impossible or at least merit an understandable warning in the documentation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 06:13 Message: Logged In: YES user_id=80475 Actually, it should NOT be documented because 1) it is an implementation specific detail and 2) using key and cmp together is almost always the wrong thing to do. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-03 22:22 Message: Logged In: YES user_id=1188172 Thanks for the report and the patch. Committed as Doc/lib/libstdtypes.tex r1.183, r1.170.2.12. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-03 22:00 Message: Logged In: YES user_id=174455 I have submittted a doc patch (#1231890) that adds a note that reads: If both key and cmp are supplied the key function is applied before the cmp function. (You can check listsort in listobject.c to verify) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 From noreply at sourceforge.net Mon Jul 4 12:21:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 03:21:57 -0700 Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage Message-ID: Bugs item #1162912, was opened at 2005-03-14 12:20 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Stefan Behnel (scoder) >Assigned to: Raymond Hettinger (rhettinger) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 12:21 Message: Logged In: YES user_id=1188172 But in this case, don't you think that the implementor would in every case look up how it's done in the source code? Raymond, please decide. ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2005-07-04 11:52 Message: Logged In: YES user_id=313935 ... except, for example, when implementing classes that behave like builtins and stdlib. So, if it's an implementation detail, why not document that and give the hint that the current CPython implementation applies key before cmp? I do not think it matters that using them together is "almost always the wrong thing to do". In that case, it should either become impossible or at least merit an understandable warning in the documentation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 06:13 Message: Logged In: YES user_id=80475 Actually, it should NOT be documented because 1) it is an implementation specific detail and 2) using key and cmp together is almost always the wrong thing to do. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-03 22:22 Message: Logged In: YES user_id=1188172 Thanks for the report and the patch. Committed as Doc/lib/libstdtypes.tex r1.183, r1.170.2.12. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-03 22:00 Message: Logged In: YES user_id=174455 I have submittted a doc patch (#1231890) that adds a note that reads: If both key and cmp are supplied the key function is applied before the cmp function. (You can check listsort in listobject.c to verify) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 From noreply at sourceforge.net Mon Jul 4 15:01:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 06:01:16 -0700 Subject: [ python-Bugs-1177468 ] random.py/os.urandom robustness Message-ID: Bugs item #1177468, was opened at 2005-04-06 03:03 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 Please note that this message 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: Fazal Majid (majid) Assigned to: Nobody/Anonymous (nobody) Summary: random.py/os.urandom robustness Initial Comment: Python 2.4.1 now uses os.urandom() to seed the random number generator. This is mostly an improvement, but can lead to subtle regression bugs. os.urandom() will open /dev/urandom on demand, e.g. when random.Random.seed() is called, and keep it alive as os._urandomfd. It is standard programming practice for a daemon process to close file descriptors it has inherited from its parent process, and if it closes the file descriptor corresponding to os._urandomfd, the os module is blissfully unaware and the next time os.urandom() is called, it will try to read from a closed file descriptor (or worse, a new one opened since), with unpredictable results. My recommendation would be to make os.urandom() open /dev/urandom each time and not keep a persistent file descripto. This will be slightly slower, but more robust. I am not sure how I feel about a standard library function steal a file descriptor slot forever, specially when os.urandom() is probably going to be called only once in the lifetime of a program, when the random module is seeded. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-07-04 15:01 Message: Logged In: YES user_id=344921 This bug is a major problem for us as well. This bug also breaks the subprocess module. Try, for example: subprocess.Popen(["ls"], close_fds=1, preexec_fn=lambda: os.urandom(4)) I agree with lcaamano; the library should NOT cache a file descriptor by default. Correctness and robustness is more important than speed. Has anyone really been able to verify that the performance with opening /dev/urandom each time is a problem? If it is, we could add a new function to the os module that activates the fd caching. If you have been calling this function, you have indicated that you are aware of the problem and will not close the cached fd. Legacy code will continue to function. ---------------------------------------------------------------------- Comment By: pocket_aces (pocket_aces) Date: 2005-06-09 00:10 Message: Logged In: YES user_id=1293510 We ran across this problem when we upgraded to 2.4. We use python embedded in a multi-threaded C++ process and use multiple subinterpreters. When a subinterpreter shuts down and the os module unloads, os._urandomfd is not closed because it is not a file object but rather just an integer. As such, after a while, our process had hundreds of dangling open file descriptors to /dev/urandom. I would think, at the very least, if this were a file object, it would be closed when the module was unloaded (the deallocator for fileobject closes the file). However, that doesn't make it any easier for those who are forking processes. Probably the best bet is to close it after reading the data. If you need a "high performance, multiple seek" urandom, just open /dev/urandom yourself. Either way, this bug is not invalid and needs to be addressed. My 2 cents.. --J ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 15:17 Message: Logged In: YES user_id=279987 Here's a reference: http://tinyurl.com/b8mk3 The relevant post: ============================================ On 25 Feb 2001 10:48:22 GMT Casper H.S. Dik - Network Security Engineer wrote: | Solaris at various times used a cached /dev/zero fd both for mapping | thread stacks and even one for the runtime linker. | The runtime linker was mostly fine, but the thread library did have | problems with people closing fds. We since added MAP_ANON and no | longer require open("/dev/zero") . THe caaching of fds was gotten | rid of before that. | | There are valid reasons to close all fds; e.g., if you really don't | want to inherit and (you're a daemon and don't care). | | In most cases, though, the "close all" stuff performed by shells | and such at statup serves no purpose. (Other than causing more bugs ) So the dilemma is that closing fds can cause problems and leaving them open can cause problems, when a forked child does this. This seems to tell me that hiding fds in libraries and objects is a bad idea because processes need to know what is safe to close and/or what needs to be left open. ====================================== If the python library had some module or global list of opened file descriptors, then it would be OK to expect programs to keep those open across fork/exec. Something like: from os import opened_fds And then it would be no problem to skip those when closing fds. Otherwise, your nice daemon code that deals with _urandom_fd will break later on when somebody caches another fd somewhere else in the standard library. Also, the proposed os.daemonize() function that knows about its own fds would also work. Still, the most robust solution is not to cache open fds in the library or perhaps catch the EBADF exception and reopen. There are several solutions but closing this bug as invalid doesn't seem an appropriate one. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 14:04 Message: Logged In: YES user_id=279987 I don't think so. One of the rules in libc, the standard C library, is that it cannot cache file descriptors for that same reason. This is not new. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-20 04:49 Message: Logged In: YES user_id=81797 Conversely, I would say that it's unreasonable to expect other things not to break if you go through and close file descriptors that the standard library has opened. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 04:31 Message: Logged In: YES user_id=279987 Clearly broken? Hardly. Daemonization code is not the only place where it's recommend and standard practice to close file descriptors. It's unreasonable to expect python programs to keep track of all the possible file descriptors the python library might cache to make sure it doesn't close them in all the daemonization routines ... btw, contrary to standard unix programming practices. Are there any other file descriptors we should know about? ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-20 00:27 Message: Logged In: YES user_id=81797 Perhaps the best way to resolve this would be for the standard library to provide code that either does the daemonize process, or at least does the closing of the sockets that may be done as part of the daemonize, that way it's clear what the "right" way is to do it. Thoughts? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-19 22:05 Message: Logged In: YES user_id=6380 I recommend to close this as invalid. The daemonization code is clearly broken. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-19 19:49 Message: Logged In: YES user_id=110477 Modifying the system os.py is not a good idea. A better work-around is to skip the /dev/urandom fd when you are closing all fds. This is the code we use: def close_fd(): # close all inherited file descriptors start_fd = 3 # Python 2.4.1 and later use /dev/urandom to seed the random module's RNG # a file descriptor is kept internally as os._urandomfd (created on demand # the first time os.urandom() is called), and should not be closed try: os.urandom(4) urandom_fd = getattr(os, '_urandomfd', None) except AttributeError: urandom_fd = None if '-close_fd' in sys.argv: start_fd = int(sys.argv[sys.argv.index('-close_fd') + 1]) for fd in range(start_fd, 256): if fd == urandom_fd: continue try: os.close(fd) except OSError: pass ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-19 18:53 Message: Logged In: YES user_id=279987 We're facing this problem. We're thinking of patching our os.py module to always open /dev/urandom on every call. Does anybody know if this would have any bad consequences other than the obvious system call overhead? BTW, here's the traceback we get. As you probably can guess, something called os.urandom before we closed all file descriptors in the daemonizing code and it then failed when os.urandom tried to use the cached fd. Traceback (most recent call last): File "/opt/race/share/sw/common/bin/dpmd", line 27, in ? dpmd().run() File "Linux/CommandLineApp.py", line 336, in run File "Linux/daemonbase.py", line 324, in main File "Linux/server.py", line 61, in addServices File "Linux/dpmd.py", line 293, in __init__ File "Linux/threadutils.py", line 44, in start File "Linux/xmlrpcd.py", line 165, in createThread File "Linux/threadutils.py", line 126, in __init__ File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 423, in NamedTemporaryFile dir = gettempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 262, in gettempdir tempdir = _get_default_tempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 185, in _get_default_tempdir namer = _RandomNameSequence() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 121, in __init__ self.rng = _Random() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 96, in __init__ self.seed(x) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 110, in seed a = long(_hexlify(_urandom(16)), 16) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/ os.py", line 728, in urandom bytes += read(_urandomfd, n - len(bytes)) OSError : [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 11:04 Message: Logged In: YES user_id=81797 The child is a copy of the parent. Therefore, if in the parent you open a few file descriptors, those are the ones you should close in the child. That is exactly what I've done in the past when I forked a child, and it has worked very well. I suspect Stevens would make an exception to his guideline in the event that closing a file descriptor results in library routine failures. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 09:27 Message: Logged In: YES user_id=110477 Unfortunately, catching exceptions is not sufficient - the file descriptor may have been reassigned. Fortunately in my case, to a socket which raised ENOSYS, but if it had been a normal file, this would have been much harder to trace because reading from it would cause weird errors for readers of the reassigned fd without triggering an exception in os.urandom() itself. As for not closing file descriptors you haven't opened yourself, if the process is the result of a vfork/exec (in my case Python processes started by a cluster manager, sort of like init), the child process has no clue what file descriptors, sockets or the like it has inherited from its parent process, and the safest course is to close them all. Indeed, that's what W. Richard Stevens recommends in "Advanced Programming for the UNIX environment". As far as I can tell, os.urandom() is used mostly to seed the RNG in random.py, and thus is not a high-drequency operation. It is going to be very hard to document this adequately for coders to defend against - in my case, the problem was being triggered by os.tempnam() from within Webware's PSP compiler. There are so many functions that depend on random (sometimes in non-obvious ways), you can't flag them all so their users know they should use urandomcleanup. One possible solution would be for os.py to offer a go_daemon() function that implements the fd closing, signal masking, process group and terminal disassociation required by true daemons. This function could take care of internal book-keeping like calling urandomcleanup. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 09:20 Message: Logged In: YES user_id=81797 Yeah, I was thinking the same thing. It doesn't address the consumed file handle, but it does address the "robustness" issue. It complicates the code, but should work. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-06 09:11 Message: Logged In: YES user_id=21627 To add robustness, it would be possible to catch read errors from _urandomfd, and try reopening it if it got somehow closed. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 05:11 Message: Logged In: YES user_id=81797 Just providing some feedback: I'm able to reproduce this. Importing random will cause this file descriptor to be called. Opening urandom on every call could lead to unacceptable syscall overhead for some. Perhaps there should be a "urandomcleanup" method that closes the file descriptor, and then random could get the bytes from urandom(), and clean up after itself? Personally, I only clean up the file descriptors I have allocated when I fork a new process. On the one hand I agree with you about sucking up a fd in the standard library, but on the other hand I'm thinking that you just shouldn't be closing file descriptors for stuff you'll be needing. That's my two cents on this bug. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 03:06 Message: Logged In: YES user_id=110477 There are many modules that have a dependency on random, for instance os.tempnam(), and a program could well inadvertently use it before closing file descriptors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 From noreply at sourceforge.net Mon Jul 4 16:03:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 07:03:07 -0700 Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage Message-ID: Bugs item #1162912, was opened at 2005-03-14 06:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Raymond Hettinger (rhettinger) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 09:03 Message: Logged In: YES user_id=80475 The docs are not meant to capture all implementation details. Building lookalike objects only need to match the documented, promised behavior -- the rest can be arbitrary. And, yes, it does matter that using the two together is almost always the wrong thing to do. The docs are supposed to point people in the right direction -- it makes Python easier to use. Please revert this patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 05:21 Message: Logged In: YES user_id=1188172 But in this case, don't you think that the implementor would in every case look up how it's done in the source code? Raymond, please decide. ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2005-07-04 04:52 Message: Logged In: YES user_id=313935 ... except, for example, when implementing classes that behave like builtins and stdlib. So, if it's an implementation detail, why not document that and give the hint that the current CPython implementation applies key before cmp? I do not think it matters that using them together is "almost always the wrong thing to do". In that case, it should either become impossible or at least merit an understandable warning in the documentation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-03 23:13 Message: Logged In: YES user_id=80475 Actually, it should NOT be documented because 1) it is an implementation specific detail and 2) using key and cmp together is almost always the wrong thing to do. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-03 15:22 Message: Logged In: YES user_id=1188172 Thanks for the report and the patch. Committed as Doc/lib/libstdtypes.tex r1.183, r1.170.2.12. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-03 15:00 Message: Logged In: YES user_id=174455 I have submittted a doc patch (#1231890) that adds a note that reads: If both key and cmp are supplied the key function is applied before the cmp function. (You can check listsort in listobject.c to verify) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 From noreply at sourceforge.net Mon Jul 4 16:20:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 07:20:09 -0700 Subject: [ python-Bugs-1162912 ] typesseq-mutable lacks note on combined key/cmp usage Message-ID: Bugs item #1162912, was opened at 2005-03-14 12:20 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 Please note that this 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: Rejected Priority: 5 Submitted By: Stefan Behnel (scoder) >Assigned to: Nobody/Anonymous (nobody) Summary: typesseq-mutable lacks note on combined key/cmp usage Initial Comment: The documentation about list.sort() and sorted() does not state how the keyword arguments cmp and key interact. Aparently, if key is supplied, cmp works on the result of the key function and no longer on the item itself. This should be documented. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 16:20 Message: Logged In: YES user_id=1188172 Done. Doc/lib/libstdtypes.tex r1.170.2.13, r1.184. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 16:03 Message: Logged In: YES user_id=80475 The docs are not meant to capture all implementation details. Building lookalike objects only need to match the documented, promised behavior -- the rest can be arbitrary. And, yes, it does matter that using the two together is almost always the wrong thing to do. The docs are supposed to point people in the right direction -- it makes Python easier to use. Please revert this patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 12:21 Message: Logged In: YES user_id=1188172 But in this case, don't you think that the implementor would in every case look up how it's done in the source code? Raymond, please decide. ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2005-07-04 11:52 Message: Logged In: YES user_id=313935 ... except, for example, when implementing classes that behave like builtins and stdlib. So, if it's an implementation detail, why not document that and give the hint that the current CPython implementation applies key before cmp? I do not think it matters that using them together is "almost always the wrong thing to do". In that case, it should either become impossible or at least merit an understandable warning in the documentation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 06:13 Message: Logged In: YES user_id=80475 Actually, it should NOT be documented because 1) it is an implementation specific detail and 2) using key and cmp together is almost always the wrong thing to do. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-03 22:22 Message: Logged In: YES user_id=1188172 Thanks for the report and the patch. Committed as Doc/lib/libstdtypes.tex r1.183, r1.170.2.12. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-03 22:00 Message: Logged In: YES user_id=174455 I have submittted a doc patch (#1231890) that adds a note that reads: If both key and cmp are supplied the key function is applied before the cmp function. (You can check listsort in listobject.c to verify) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162912&group_id=5470 From noreply at sourceforge.net Mon Jul 4 16:26:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 07:26:18 -0700 Subject: [ python-Bugs-1177468 ] random.py/os.urandom robustness Message-ID: Bugs item #1177468, was opened at 2005-04-06 03:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 Please note that this message 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: Fazal Majid (majid) >Assigned to: Raymond Hettinger (rhettinger) Summary: random.py/os.urandom robustness Initial Comment: Python 2.4.1 now uses os.urandom() to seed the random number generator. This is mostly an improvement, but can lead to subtle regression bugs. os.urandom() will open /dev/urandom on demand, e.g. when random.Random.seed() is called, and keep it alive as os._urandomfd. It is standard programming practice for a daemon process to close file descriptors it has inherited from its parent process, and if it closes the file descriptor corresponding to os._urandomfd, the os module is blissfully unaware and the next time os.urandom() is called, it will try to read from a closed file descriptor (or worse, a new one opened since), with unpredictable results. My recommendation would be to make os.urandom() open /dev/urandom each time and not keep a persistent file descripto. This will be slightly slower, but more robust. I am not sure how I feel about a standard library function steal a file descriptor slot forever, specially when os.urandom() is probably going to be called only once in the lifetime of a program, when the random module is seeded. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 16:26 Message: Logged In: YES user_id=1188172 Attaching a patch for Lib/os.py, fixing this on Unix. On Windows, a completely different method is used for urandom, so I think it is not relevant here. Please review. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-07-04 15:01 Message: Logged In: YES user_id=344921 This bug is a major problem for us as well. This bug also breaks the subprocess module. Try, for example: subprocess.Popen(["ls"], close_fds=1, preexec_fn=lambda: os.urandom(4)) I agree with lcaamano; the library should NOT cache a file descriptor by default. Correctness and robustness is more important than speed. Has anyone really been able to verify that the performance with opening /dev/urandom each time is a problem? If it is, we could add a new function to the os module that activates the fd caching. If you have been calling this function, you have indicated that you are aware of the problem and will not close the cached fd. Legacy code will continue to function. ---------------------------------------------------------------------- Comment By: pocket_aces (pocket_aces) Date: 2005-06-09 00:10 Message: Logged In: YES user_id=1293510 We ran across this problem when we upgraded to 2.4. We use python embedded in a multi-threaded C++ process and use multiple subinterpreters. When a subinterpreter shuts down and the os module unloads, os._urandomfd is not closed because it is not a file object but rather just an integer. As such, after a while, our process had hundreds of dangling open file descriptors to /dev/urandom. I would think, at the very least, if this were a file object, it would be closed when the module was unloaded (the deallocator for fileobject closes the file). However, that doesn't make it any easier for those who are forking processes. Probably the best bet is to close it after reading the data. If you need a "high performance, multiple seek" urandom, just open /dev/urandom yourself. Either way, this bug is not invalid and needs to be addressed. My 2 cents.. --J ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 15:17 Message: Logged In: YES user_id=279987 Here's a reference: http://tinyurl.com/b8mk3 The relevant post: ============================================ On 25 Feb 2001 10:48:22 GMT Casper H.S. Dik - Network Security Engineer wrote: | Solaris at various times used a cached /dev/zero fd both for mapping | thread stacks and even one for the runtime linker. | The runtime linker was mostly fine, but the thread library did have | problems with people closing fds. We since added MAP_ANON and no | longer require open("/dev/zero") . THe caaching of fds was gotten | rid of before that. | | There are valid reasons to close all fds; e.g., if you really don't | want to inherit and (you're a daemon and don't care). | | In most cases, though, the "close all" stuff performed by shells | and such at statup serves no purpose. (Other than causing more bugs ) So the dilemma is that closing fds can cause problems and leaving them open can cause problems, when a forked child does this. This seems to tell me that hiding fds in libraries and objects is a bad idea because processes need to know what is safe to close and/or what needs to be left open. ====================================== If the python library had some module or global list of opened file descriptors, then it would be OK to expect programs to keep those open across fork/exec. Something like: from os import opened_fds And then it would be no problem to skip those when closing fds. Otherwise, your nice daemon code that deals with _urandom_fd will break later on when somebody caches another fd somewhere else in the standard library. Also, the proposed os.daemonize() function that knows about its own fds would also work. Still, the most robust solution is not to cache open fds in the library or perhaps catch the EBADF exception and reopen. There are several solutions but closing this bug as invalid doesn't seem an appropriate one. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 14:04 Message: Logged In: YES user_id=279987 I don't think so. One of the rules in libc, the standard C library, is that it cannot cache file descriptors for that same reason. This is not new. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-20 04:49 Message: Logged In: YES user_id=81797 Conversely, I would say that it's unreasonable to expect other things not to break if you go through and close file descriptors that the standard library has opened. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 04:31 Message: Logged In: YES user_id=279987 Clearly broken? Hardly. Daemonization code is not the only place where it's recommend and standard practice to close file descriptors. It's unreasonable to expect python programs to keep track of all the possible file descriptors the python library might cache to make sure it doesn't close them in all the daemonization routines ... btw, contrary to standard unix programming practices. Are there any other file descriptors we should know about? ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-20 00:27 Message: Logged In: YES user_id=81797 Perhaps the best way to resolve this would be for the standard library to provide code that either does the daemonize process, or at least does the closing of the sockets that may be done as part of the daemonize, that way it's clear what the "right" way is to do it. Thoughts? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-19 22:05 Message: Logged In: YES user_id=6380 I recommend to close this as invalid. The daemonization code is clearly broken. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-19 19:49 Message: Logged In: YES user_id=110477 Modifying the system os.py is not a good idea. A better work-around is to skip the /dev/urandom fd when you are closing all fds. This is the code we use: def close_fd(): # close all inherited file descriptors start_fd = 3 # Python 2.4.1 and later use /dev/urandom to seed the random module's RNG # a file descriptor is kept internally as os._urandomfd (created on demand # the first time os.urandom() is called), and should not be closed try: os.urandom(4) urandom_fd = getattr(os, '_urandomfd', None) except AttributeError: urandom_fd = None if '-close_fd' in sys.argv: start_fd = int(sys.argv[sys.argv.index('-close_fd') + 1]) for fd in range(start_fd, 256): if fd == urandom_fd: continue try: os.close(fd) except OSError: pass ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-19 18:53 Message: Logged In: YES user_id=279987 We're facing this problem. We're thinking of patching our os.py module to always open /dev/urandom on every call. Does anybody know if this would have any bad consequences other than the obvious system call overhead? BTW, here's the traceback we get. As you probably can guess, something called os.urandom before we closed all file descriptors in the daemonizing code and it then failed when os.urandom tried to use the cached fd. Traceback (most recent call last): File "/opt/race/share/sw/common/bin/dpmd", line 27, in ? dpmd().run() File "Linux/CommandLineApp.py", line 336, in run File "Linux/daemonbase.py", line 324, in main File "Linux/server.py", line 61, in addServices File "Linux/dpmd.py", line 293, in __init__ File "Linux/threadutils.py", line 44, in start File "Linux/xmlrpcd.py", line 165, in createThread File "Linux/threadutils.py", line 126, in __init__ File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 423, in NamedTemporaryFile dir = gettempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 262, in gettempdir tempdir = _get_default_tempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 185, in _get_default_tempdir namer = _RandomNameSequence() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 121, in __init__ self.rng = _Random() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 96, in __init__ self.seed(x) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 110, in seed a = long(_hexlify(_urandom(16)), 16) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/ os.py", line 728, in urandom bytes += read(_urandomfd, n - len(bytes)) OSError : [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 11:04 Message: Logged In: YES user_id=81797 The child is a copy of the parent. Therefore, if in the parent you open a few file descriptors, those are the ones you should close in the child. That is exactly what I've done in the past when I forked a child, and it has worked very well. I suspect Stevens would make an exception to his guideline in the event that closing a file descriptor results in library routine failures. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 09:27 Message: Logged In: YES user_id=110477 Unfortunately, catching exceptions is not sufficient - the file descriptor may have been reassigned. Fortunately in my case, to a socket which raised ENOSYS, but if it had been a normal file, this would have been much harder to trace because reading from it would cause weird errors for readers of the reassigned fd without triggering an exception in os.urandom() itself. As for not closing file descriptors you haven't opened yourself, if the process is the result of a vfork/exec (in my case Python processes started by a cluster manager, sort of like init), the child process has no clue what file descriptors, sockets or the like it has inherited from its parent process, and the safest course is to close them all. Indeed, that's what W. Richard Stevens recommends in "Advanced Programming for the UNIX environment". As far as I can tell, os.urandom() is used mostly to seed the RNG in random.py, and thus is not a high-drequency operation. It is going to be very hard to document this adequately for coders to defend against - in my case, the problem was being triggered by os.tempnam() from within Webware's PSP compiler. There are so many functions that depend on random (sometimes in non-obvious ways), you can't flag them all so their users know they should use urandomcleanup. One possible solution would be for os.py to offer a go_daemon() function that implements the fd closing, signal masking, process group and terminal disassociation required by true daemons. This function could take care of internal book-keeping like calling urandomcleanup. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 09:20 Message: Logged In: YES user_id=81797 Yeah, I was thinking the same thing. It doesn't address the consumed file handle, but it does address the "robustness" issue. It complicates the code, but should work. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-06 09:11 Message: Logged In: YES user_id=21627 To add robustness, it would be possible to catch read errors from _urandomfd, and try reopening it if it got somehow closed. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 05:11 Message: Logged In: YES user_id=81797 Just providing some feedback: I'm able to reproduce this. Importing random will cause this file descriptor to be called. Opening urandom on every call could lead to unacceptable syscall overhead for some. Perhaps there should be a "urandomcleanup" method that closes the file descriptor, and then random could get the bytes from urandom(), and clean up after itself? Personally, I only clean up the file descriptors I have allocated when I fork a new process. On the one hand I agree with you about sucking up a fd in the standard library, but on the other hand I'm thinking that you just shouldn't be closing file descriptors for stuff you'll be needing. That's my two cents on this bug. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 03:06 Message: Logged In: YES user_id=110477 There are many modules that have a dependency on random, for instance os.tempnam(), and a program could well inadvertently use it before closing file descriptors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 From noreply at sourceforge.net Mon Jul 4 16:56:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 07:56:35 -0700 Subject: [ python-Bugs-1177468 ] random.py/os.urandom robustness Message-ID: Bugs item #1177468, was opened at 2005-04-05 20:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 Please note that this message 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: Fazal Majid (majid) >Assigned to: Martin v. L?wis (loewis) Summary: random.py/os.urandom robustness Initial Comment: Python 2.4.1 now uses os.urandom() to seed the random number generator. This is mostly an improvement, but can lead to subtle regression bugs. os.urandom() will open /dev/urandom on demand, e.g. when random.Random.seed() is called, and keep it alive as os._urandomfd. It is standard programming practice for a daemon process to close file descriptors it has inherited from its parent process, and if it closes the file descriptor corresponding to os._urandomfd, the os module is blissfully unaware and the next time os.urandom() is called, it will try to read from a closed file descriptor (or worse, a new one opened since), with unpredictable results. My recommendation would be to make os.urandom() open /dev/urandom each time and not keep a persistent file descripto. This will be slightly slower, but more robust. I am not sure how I feel about a standard library function steal a file descriptor slot forever, specially when os.urandom() is probably going to be called only once in the lifetime of a program, when the random module is seeded. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 09:56 Message: Logged In: YES user_id=80475 I'm on Windows so cannot be of much use on the patch review. It looks fine to me and I agree that something ought to be done. MvL reviewed and posted the original patch so he may be better able to comment on this patch. Alternatively, Peter A. can review/approve it. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 09:26 Message: Logged In: YES user_id=1188172 Attaching a patch for Lib/os.py, fixing this on Unix. On Windows, a completely different method is used for urandom, so I think it is not relevant here. Please review. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-07-04 08:01 Message: Logged In: YES user_id=344921 This bug is a major problem for us as well. This bug also breaks the subprocess module. Try, for example: subprocess.Popen(["ls"], close_fds=1, preexec_fn=lambda: os.urandom(4)) I agree with lcaamano; the library should NOT cache a file descriptor by default. Correctness and robustness is more important than speed. Has anyone really been able to verify that the performance with opening /dev/urandom each time is a problem? If it is, we could add a new function to the os module that activates the fd caching. If you have been calling this function, you have indicated that you are aware of the problem and will not close the cached fd. Legacy code will continue to function. ---------------------------------------------------------------------- Comment By: pocket_aces (pocket_aces) Date: 2005-06-08 17:10 Message: Logged In: YES user_id=1293510 We ran across this problem when we upgraded to 2.4. We use python embedded in a multi-threaded C++ process and use multiple subinterpreters. When a subinterpreter shuts down and the os module unloads, os._urandomfd is not closed because it is not a file object but rather just an integer. As such, after a while, our process had hundreds of dangling open file descriptors to /dev/urandom. I would think, at the very least, if this were a file object, it would be closed when the module was unloaded (the deallocator for fileobject closes the file). However, that doesn't make it any easier for those who are forking processes. Probably the best bet is to close it after reading the data. If you need a "high performance, multiple seek" urandom, just open /dev/urandom yourself. Either way, this bug is not invalid and needs to be addressed. My 2 cents.. --J ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 08:17 Message: Logged In: YES user_id=279987 Here's a reference: http://tinyurl.com/b8mk3 The relevant post: ============================================ On 25 Feb 2001 10:48:22 GMT Casper H.S. Dik - Network Security Engineer wrote: | Solaris at various times used a cached /dev/zero fd both for mapping | thread stacks and even one for the runtime linker. | The runtime linker was mostly fine, but the thread library did have | problems with people closing fds. We since added MAP_ANON and no | longer require open("/dev/zero") . THe caaching of fds was gotten | rid of before that. | | There are valid reasons to close all fds; e.g., if you really don't | want to inherit and (you're a daemon and don't care). | | In most cases, though, the "close all" stuff performed by shells | and such at statup serves no purpose. (Other than causing more bugs ) So the dilemma is that closing fds can cause problems and leaving them open can cause problems, when a forked child does this. This seems to tell me that hiding fds in libraries and objects is a bad idea because processes need to know what is safe to close and/or what needs to be left open. ====================================== If the python library had some module or global list of opened file descriptors, then it would be OK to expect programs to keep those open across fork/exec. Something like: from os import opened_fds And then it would be no problem to skip those when closing fds. Otherwise, your nice daemon code that deals with _urandom_fd will break later on when somebody caches another fd somewhere else in the standard library. Also, the proposed os.daemonize() function that knows about its own fds would also work. Still, the most robust solution is not to cache open fds in the library or perhaps catch the EBADF exception and reopen. There are several solutions but closing this bug as invalid doesn't seem an appropriate one. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 07:04 Message: Logged In: YES user_id=279987 I don't think so. One of the rules in libc, the standard C library, is that it cannot cache file descriptors for that same reason. This is not new. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-19 21:49 Message: Logged In: YES user_id=81797 Conversely, I would say that it's unreasonable to expect other things not to break if you go through and close file descriptors that the standard library has opened. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-19 21:31 Message: Logged In: YES user_id=279987 Clearly broken? Hardly. Daemonization code is not the only place where it's recommend and standard practice to close file descriptors. It's unreasonable to expect python programs to keep track of all the possible file descriptors the python library might cache to make sure it doesn't close them in all the daemonization routines ... btw, contrary to standard unix programming practices. Are there any other file descriptors we should know about? ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-19 17:27 Message: Logged In: YES user_id=81797 Perhaps the best way to resolve this would be for the standard library to provide code that either does the daemonize process, or at least does the closing of the sockets that may be done as part of the daemonize, that way it's clear what the "right" way is to do it. Thoughts? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-19 15:05 Message: Logged In: YES user_id=6380 I recommend to close this as invalid. The daemonization code is clearly broken. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-19 12:49 Message: Logged In: YES user_id=110477 Modifying the system os.py is not a good idea. A better work-around is to skip the /dev/urandom fd when you are closing all fds. This is the code we use: def close_fd(): # close all inherited file descriptors start_fd = 3 # Python 2.4.1 and later use /dev/urandom to seed the random module's RNG # a file descriptor is kept internally as os._urandomfd (created on demand # the first time os.urandom() is called), and should not be closed try: os.urandom(4) urandom_fd = getattr(os, '_urandomfd', None) except AttributeError: urandom_fd = None if '-close_fd' in sys.argv: start_fd = int(sys.argv[sys.argv.index('-close_fd') + 1]) for fd in range(start_fd, 256): if fd == urandom_fd: continue try: os.close(fd) except OSError: pass ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-19 11:53 Message: Logged In: YES user_id=279987 We're facing this problem. We're thinking of patching our os.py module to always open /dev/urandom on every call. Does anybody know if this would have any bad consequences other than the obvious system call overhead? BTW, here's the traceback we get. As you probably can guess, something called os.urandom before we closed all file descriptors in the daemonizing code and it then failed when os.urandom tried to use the cached fd. Traceback (most recent call last): File "/opt/race/share/sw/common/bin/dpmd", line 27, in ? dpmd().run() File "Linux/CommandLineApp.py", line 336, in run File "Linux/daemonbase.py", line 324, in main File "Linux/server.py", line 61, in addServices File "Linux/dpmd.py", line 293, in __init__ File "Linux/threadutils.py", line 44, in start File "Linux/xmlrpcd.py", line 165, in createThread File "Linux/threadutils.py", line 126, in __init__ File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 423, in NamedTemporaryFile dir = gettempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 262, in gettempdir tempdir = _get_default_tempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 185, in _get_default_tempdir namer = _RandomNameSequence() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 121, in __init__ self.rng = _Random() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 96, in __init__ self.seed(x) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 110, in seed a = long(_hexlify(_urandom(16)), 16) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/ os.py", line 728, in urandom bytes += read(_urandomfd, n - len(bytes)) OSError : [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 04:04 Message: Logged In: YES user_id=81797 The child is a copy of the parent. Therefore, if in the parent you open a few file descriptors, those are the ones you should close in the child. That is exactly what I've done in the past when I forked a child, and it has worked very well. I suspect Stevens would make an exception to his guideline in the event that closing a file descriptor results in library routine failures. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 02:27 Message: Logged In: YES user_id=110477 Unfortunately, catching exceptions is not sufficient - the file descriptor may have been reassigned. Fortunately in my case, to a socket which raised ENOSYS, but if it had been a normal file, this would have been much harder to trace because reading from it would cause weird errors for readers of the reassigned fd without triggering an exception in os.urandom() itself. As for not closing file descriptors you haven't opened yourself, if the process is the result of a vfork/exec (in my case Python processes started by a cluster manager, sort of like init), the child process has no clue what file descriptors, sockets or the like it has inherited from its parent process, and the safest course is to close them all. Indeed, that's what W. Richard Stevens recommends in "Advanced Programming for the UNIX environment". As far as I can tell, os.urandom() is used mostly to seed the RNG in random.py, and thus is not a high-drequency operation. It is going to be very hard to document this adequately for coders to defend against - in my case, the problem was being triggered by os.tempnam() from within Webware's PSP compiler. There are so many functions that depend on random (sometimes in non-obvious ways), you can't flag them all so their users know they should use urandomcleanup. One possible solution would be for os.py to offer a go_daemon() function that implements the fd closing, signal masking, process group and terminal disassociation required by true daemons. This function could take care of internal book-keeping like calling urandomcleanup. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 02:20 Message: Logged In: YES user_id=81797 Yeah, I was thinking the same thing. It doesn't address the consumed file handle, but it does address the "robustness" issue. It complicates the code, but should work. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-06 02:11 Message: Logged In: YES user_id=21627 To add robustness, it would be possible to catch read errors from _urandomfd, and try reopening it if it got somehow closed. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-05 22:11 Message: Logged In: YES user_id=81797 Just providing some feedback: I'm able to reproduce this. Importing random will cause this file descriptor to be called. Opening urandom on every call could lead to unacceptable syscall overhead for some. Perhaps there should be a "urandomcleanup" method that closes the file descriptor, and then random could get the bytes from urandom(), and clean up after itself? Personally, I only clean up the file descriptors I have allocated when I fork a new process. On the one hand I agree with you about sucking up a fd in the standard library, but on the other hand I'm thinking that you just shouldn't be closing file descriptors for stuff you'll be needing. That's my two cents on this bug. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-05 20:06 Message: Logged In: YES user_id=110477 There are many modules that have a dependency on random, for instance os.tempnam(), and a program could well inadvertently use it before closing file descriptors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 From noreply at sourceforge.net Mon Jul 4 17:54:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 08:54:21 -0700 Subject: [ python-Bugs-1177468 ] random.py/os.urandom robustness Message-ID: Bugs item #1177468, was opened at 2005-04-06 03:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 Please note that this message 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: Accepted Priority: 5 Submitted By: Fazal Majid (majid) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: random.py/os.urandom robustness Initial Comment: Python 2.4.1 now uses os.urandom() to seed the random number generator. This is mostly an improvement, but can lead to subtle regression bugs. os.urandom() will open /dev/urandom on demand, e.g. when random.Random.seed() is called, and keep it alive as os._urandomfd. It is standard programming practice for a daemon process to close file descriptors it has inherited from its parent process, and if it closes the file descriptor corresponding to os._urandomfd, the os module is blissfully unaware and the next time os.urandom() is called, it will try to read from a closed file descriptor (or worse, a new one opened since), with unpredictable results. My recommendation would be to make os.urandom() open /dev/urandom each time and not keep a persistent file descripto. This will be slightly slower, but more robust. I am not sure how I feel about a standard library function steal a file descriptor slot forever, specially when os.urandom() is probably going to be called only once in the lifetime of a program, when the random module is seeded. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-04 17:54 Message: Logged In: YES user_id=21627 The patch is fine, please apply - both to the trunk and to 2.4. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 16:56 Message: Logged In: YES user_id=80475 I'm on Windows so cannot be of much use on the patch review. It looks fine to me and I agree that something ought to be done. MvL reviewed and posted the original patch so he may be better able to comment on this patch. Alternatively, Peter A. can review/approve it. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 16:26 Message: Logged In: YES user_id=1188172 Attaching a patch for Lib/os.py, fixing this on Unix. On Windows, a completely different method is used for urandom, so I think it is not relevant here. Please review. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-07-04 15:01 Message: Logged In: YES user_id=344921 This bug is a major problem for us as well. This bug also breaks the subprocess module. Try, for example: subprocess.Popen(["ls"], close_fds=1, preexec_fn=lambda: os.urandom(4)) I agree with lcaamano; the library should NOT cache a file descriptor by default. Correctness and robustness is more important than speed. Has anyone really been able to verify that the performance with opening /dev/urandom each time is a problem? If it is, we could add a new function to the os module that activates the fd caching. If you have been calling this function, you have indicated that you are aware of the problem and will not close the cached fd. Legacy code will continue to function. ---------------------------------------------------------------------- Comment By: pocket_aces (pocket_aces) Date: 2005-06-09 00:10 Message: Logged In: YES user_id=1293510 We ran across this problem when we upgraded to 2.4. We use python embedded in a multi-threaded C++ process and use multiple subinterpreters. When a subinterpreter shuts down and the os module unloads, os._urandomfd is not closed because it is not a file object but rather just an integer. As such, after a while, our process had hundreds of dangling open file descriptors to /dev/urandom. I would think, at the very least, if this were a file object, it would be closed when the module was unloaded (the deallocator for fileobject closes the file). However, that doesn't make it any easier for those who are forking processes. Probably the best bet is to close it after reading the data. If you need a "high performance, multiple seek" urandom, just open /dev/urandom yourself. Either way, this bug is not invalid and needs to be addressed. My 2 cents.. --J ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 15:17 Message: Logged In: YES user_id=279987 Here's a reference: http://tinyurl.com/b8mk3 The relevant post: ============================================ On 25 Feb 2001 10:48:22 GMT Casper H.S. Dik - Network Security Engineer wrote: | Solaris at various times used a cached /dev/zero fd both for mapping | thread stacks and even one for the runtime linker. | The runtime linker was mostly fine, but the thread library did have | problems with people closing fds. We since added MAP_ANON and no | longer require open("/dev/zero") . THe caaching of fds was gotten | rid of before that. | | There are valid reasons to close all fds; e.g., if you really don't | want to inherit and (you're a daemon and don't care). | | In most cases, though, the "close all" stuff performed by shells | and such at statup serves no purpose. (Other than causing more bugs ) So the dilemma is that closing fds can cause problems and leaving them open can cause problems, when a forked child does this. This seems to tell me that hiding fds in libraries and objects is a bad idea because processes need to know what is safe to close and/or what needs to be left open. ====================================== If the python library had some module or global list of opened file descriptors, then it would be OK to expect programs to keep those open across fork/exec. Something like: from os import opened_fds And then it would be no problem to skip those when closing fds. Otherwise, your nice daemon code that deals with _urandom_fd will break later on when somebody caches another fd somewhere else in the standard library. Also, the proposed os.daemonize() function that knows about its own fds would also work. Still, the most robust solution is not to cache open fds in the library or perhaps catch the EBADF exception and reopen. There are several solutions but closing this bug as invalid doesn't seem an appropriate one. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 14:04 Message: Logged In: YES user_id=279987 I don't think so. One of the rules in libc, the standard C library, is that it cannot cache file descriptors for that same reason. This is not new. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-20 04:49 Message: Logged In: YES user_id=81797 Conversely, I would say that it's unreasonable to expect other things not to break if you go through and close file descriptors that the standard library has opened. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 04:31 Message: Logged In: YES user_id=279987 Clearly broken? Hardly. Daemonization code is not the only place where it's recommend and standard practice to close file descriptors. It's unreasonable to expect python programs to keep track of all the possible file descriptors the python library might cache to make sure it doesn't close them in all the daemonization routines ... btw, contrary to standard unix programming practices. Are there any other file descriptors we should know about? ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-20 00:27 Message: Logged In: YES user_id=81797 Perhaps the best way to resolve this would be for the standard library to provide code that either does the daemonize process, or at least does the closing of the sockets that may be done as part of the daemonize, that way it's clear what the "right" way is to do it. Thoughts? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-19 22:05 Message: Logged In: YES user_id=6380 I recommend to close this as invalid. The daemonization code is clearly broken. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-19 19:49 Message: Logged In: YES user_id=110477 Modifying the system os.py is not a good idea. A better work-around is to skip the /dev/urandom fd when you are closing all fds. This is the code we use: def close_fd(): # close all inherited file descriptors start_fd = 3 # Python 2.4.1 and later use /dev/urandom to seed the random module's RNG # a file descriptor is kept internally as os._urandomfd (created on demand # the first time os.urandom() is called), and should not be closed try: os.urandom(4) urandom_fd = getattr(os, '_urandomfd', None) except AttributeError: urandom_fd = None if '-close_fd' in sys.argv: start_fd = int(sys.argv[sys.argv.index('-close_fd') + 1]) for fd in range(start_fd, 256): if fd == urandom_fd: continue try: os.close(fd) except OSError: pass ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-19 18:53 Message: Logged In: YES user_id=279987 We're facing this problem. We're thinking of patching our os.py module to always open /dev/urandom on every call. Does anybody know if this would have any bad consequences other than the obvious system call overhead? BTW, here's the traceback we get. As you probably can guess, something called os.urandom before we closed all file descriptors in the daemonizing code and it then failed when os.urandom tried to use the cached fd. Traceback (most recent call last): File "/opt/race/share/sw/common/bin/dpmd", line 27, in ? dpmd().run() File "Linux/CommandLineApp.py", line 336, in run File "Linux/daemonbase.py", line 324, in main File "Linux/server.py", line 61, in addServices File "Linux/dpmd.py", line 293, in __init__ File "Linux/threadutils.py", line 44, in start File "Linux/xmlrpcd.py", line 165, in createThread File "Linux/threadutils.py", line 126, in __init__ File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 423, in NamedTemporaryFile dir = gettempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 262, in gettempdir tempdir = _get_default_tempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 185, in _get_default_tempdir namer = _RandomNameSequence() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 121, in __init__ self.rng = _Random() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 96, in __init__ self.seed(x) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 110, in seed a = long(_hexlify(_urandom(16)), 16) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/ os.py", line 728, in urandom bytes += read(_urandomfd, n - len(bytes)) OSError : [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 11:04 Message: Logged In: YES user_id=81797 The child is a copy of the parent. Therefore, if in the parent you open a few file descriptors, those are the ones you should close in the child. That is exactly what I've done in the past when I forked a child, and it has worked very well. I suspect Stevens would make an exception to his guideline in the event that closing a file descriptor results in library routine failures. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 09:27 Message: Logged In: YES user_id=110477 Unfortunately, catching exceptions is not sufficient - the file descriptor may have been reassigned. Fortunately in my case, to a socket which raised ENOSYS, but if it had been a normal file, this would have been much harder to trace because reading from it would cause weird errors for readers of the reassigned fd without triggering an exception in os.urandom() itself. As for not closing file descriptors you haven't opened yourself, if the process is the result of a vfork/exec (in my case Python processes started by a cluster manager, sort of like init), the child process has no clue what file descriptors, sockets or the like it has inherited from its parent process, and the safest course is to close them all. Indeed, that's what W. Richard Stevens recommends in "Advanced Programming for the UNIX environment". As far as I can tell, os.urandom() is used mostly to seed the RNG in random.py, and thus is not a high-drequency operation. It is going to be very hard to document this adequately for coders to defend against - in my case, the problem was being triggered by os.tempnam() from within Webware's PSP compiler. There are so many functions that depend on random (sometimes in non-obvious ways), you can't flag them all so their users know they should use urandomcleanup. One possible solution would be for os.py to offer a go_daemon() function that implements the fd closing, signal masking, process group and terminal disassociation required by true daemons. This function could take care of internal book-keeping like calling urandomcleanup. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 09:20 Message: Logged In: YES user_id=81797 Yeah, I was thinking the same thing. It doesn't address the consumed file handle, but it does address the "robustness" issue. It complicates the code, but should work. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-06 09:11 Message: Logged In: YES user_id=21627 To add robustness, it would be possible to catch read errors from _urandomfd, and try reopening it if it got somehow closed. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 05:11 Message: Logged In: YES user_id=81797 Just providing some feedback: I'm able to reproduce this. Importing random will cause this file descriptor to be called. Opening urandom on every call could lead to unacceptable syscall overhead for some. Perhaps there should be a "urandomcleanup" method that closes the file descriptor, and then random could get the bytes from urandom(), and clean up after itself? Personally, I only clean up the file descriptors I have allocated when I fork a new process. On the one hand I agree with you about sucking up a fd in the standard library, but on the other hand I'm thinking that you just shouldn't be closing file descriptors for stuff you'll be needing. That's my two cents on this bug. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 03:06 Message: Logged In: YES user_id=110477 There are many modules that have a dependency on random, for instance os.tempnam(), and a program could well inadvertently use it before closing file descriptors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 From noreply at sourceforge.net Mon Jul 4 19:17:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 10:17:10 -0700 Subject: [ python-Bugs-1177468 ] random.py/os.urandom robustness Message-ID: Bugs item #1177468, was opened at 2005-04-06 03:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 Please note that this message 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: Accepted Priority: 5 Submitted By: Fazal Majid (majid) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: random.py/os.urandom robustness Initial Comment: Python 2.4.1 now uses os.urandom() to seed the random number generator. This is mostly an improvement, but can lead to subtle regression bugs. os.urandom() will open /dev/urandom on demand, e.g. when random.Random.seed() is called, and keep it alive as os._urandomfd. It is standard programming practice for a daemon process to close file descriptors it has inherited from its parent process, and if it closes the file descriptor corresponding to os._urandomfd, the os module is blissfully unaware and the next time os.urandom() is called, it will try to read from a closed file descriptor (or worse, a new one opened since), with unpredictable results. My recommendation would be to make os.urandom() open /dev/urandom each time and not keep a persistent file descripto. This will be slightly slower, but more robust. I am not sure how I feel about a standard library function steal a file descriptor slot forever, specially when os.urandom() is probably going to be called only once in the lifetime of a program, when the random module is seeded. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 19:17 Message: Logged In: YES user_id=1188172 Committed as Lib/os.py r1.87, r1.83.2.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-04 17:54 Message: Logged In: YES user_id=21627 The patch is fine, please apply - both to the trunk and to 2.4. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-04 16:56 Message: Logged In: YES user_id=80475 I'm on Windows so cannot be of much use on the patch review. It looks fine to me and I agree that something ought to be done. MvL reviewed and posted the original patch so he may be better able to comment on this patch. Alternatively, Peter A. can review/approve it. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-04 16:26 Message: Logged In: YES user_id=1188172 Attaching a patch for Lib/os.py, fixing this on Unix. On Windows, a completely different method is used for urandom, so I think it is not relevant here. Please review. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-07-04 15:01 Message: Logged In: YES user_id=344921 This bug is a major problem for us as well. This bug also breaks the subprocess module. Try, for example: subprocess.Popen(["ls"], close_fds=1, preexec_fn=lambda: os.urandom(4)) I agree with lcaamano; the library should NOT cache a file descriptor by default. Correctness and robustness is more important than speed. Has anyone really been able to verify that the performance with opening /dev/urandom each time is a problem? If it is, we could add a new function to the os module that activates the fd caching. If you have been calling this function, you have indicated that you are aware of the problem and will not close the cached fd. Legacy code will continue to function. ---------------------------------------------------------------------- Comment By: pocket_aces (pocket_aces) Date: 2005-06-09 00:10 Message: Logged In: YES user_id=1293510 We ran across this problem when we upgraded to 2.4. We use python embedded in a multi-threaded C++ process and use multiple subinterpreters. When a subinterpreter shuts down and the os module unloads, os._urandomfd is not closed because it is not a file object but rather just an integer. As such, after a while, our process had hundreds of dangling open file descriptors to /dev/urandom. I would think, at the very least, if this were a file object, it would be closed when the module was unloaded (the deallocator for fileobject closes the file). However, that doesn't make it any easier for those who are forking processes. Probably the best bet is to close it after reading the data. If you need a "high performance, multiple seek" urandom, just open /dev/urandom yourself. Either way, this bug is not invalid and needs to be addressed. My 2 cents.. --J ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 15:17 Message: Logged In: YES user_id=279987 Here's a reference: http://tinyurl.com/b8mk3 The relevant post: ============================================ On 25 Feb 2001 10:48:22 GMT Casper H.S. Dik - Network Security Engineer wrote: | Solaris at various times used a cached /dev/zero fd both for mapping | thread stacks and even one for the runtime linker. | The runtime linker was mostly fine, but the thread library did have | problems with people closing fds. We since added MAP_ANON and no | longer require open("/dev/zero") . THe caaching of fds was gotten | rid of before that. | | There are valid reasons to close all fds; e.g., if you really don't | want to inherit and (you're a daemon and don't care). | | In most cases, though, the "close all" stuff performed by shells | and such at statup serves no purpose. (Other than causing more bugs ) So the dilemma is that closing fds can cause problems and leaving them open can cause problems, when a forked child does this. This seems to tell me that hiding fds in libraries and objects is a bad idea because processes need to know what is safe to close and/or what needs to be left open. ====================================== If the python library had some module or global list of opened file descriptors, then it would be OK to expect programs to keep those open across fork/exec. Something like: from os import opened_fds And then it would be no problem to skip those when closing fds. Otherwise, your nice daemon code that deals with _urandom_fd will break later on when somebody caches another fd somewhere else in the standard library. Also, the proposed os.daemonize() function that knows about its own fds would also work. Still, the most robust solution is not to cache open fds in the library or perhaps catch the EBADF exception and reopen. There are several solutions but closing this bug as invalid doesn't seem an appropriate one. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 14:04 Message: Logged In: YES user_id=279987 I don't think so. One of the rules in libc, the standard C library, is that it cannot cache file descriptors for that same reason. This is not new. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-20 04:49 Message: Logged In: YES user_id=81797 Conversely, I would say that it's unreasonable to expect other things not to break if you go through and close file descriptors that the standard library has opened. ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-20 04:31 Message: Logged In: YES user_id=279987 Clearly broken? Hardly. Daemonization code is not the only place where it's recommend and standard practice to close file descriptors. It's unreasonable to expect python programs to keep track of all the possible file descriptors the python library might cache to make sure it doesn't close them in all the daemonization routines ... btw, contrary to standard unix programming practices. Are there any other file descriptors we should know about? ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-20 00:27 Message: Logged In: YES user_id=81797 Perhaps the best way to resolve this would be for the standard library to provide code that either does the daemonize process, or at least does the closing of the sockets that may be done as part of the daemonize, that way it's clear what the "right" way is to do it. Thoughts? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-19 22:05 Message: Logged In: YES user_id=6380 I recommend to close this as invalid. The daemonization code is clearly broken. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-19 19:49 Message: Logged In: YES user_id=110477 Modifying the system os.py is not a good idea. A better work-around is to skip the /dev/urandom fd when you are closing all fds. This is the code we use: def close_fd(): # close all inherited file descriptors start_fd = 3 # Python 2.4.1 and later use /dev/urandom to seed the random module's RNG # a file descriptor is kept internally as os._urandomfd (created on demand # the first time os.urandom() is called), and should not be closed try: os.urandom(4) urandom_fd = getattr(os, '_urandomfd', None) except AttributeError: urandom_fd = None if '-close_fd' in sys.argv: start_fd = int(sys.argv[sys.argv.index('-close_fd') + 1]) for fd in range(start_fd, 256): if fd == urandom_fd: continue try: os.close(fd) except OSError: pass ---------------------------------------------------------------------- Comment By: Luis P Caamano (lcaamano) Date: 2005-04-19 18:53 Message: Logged In: YES user_id=279987 We're facing this problem. We're thinking of patching our os.py module to always open /dev/urandom on every call. Does anybody know if this would have any bad consequences other than the obvious system call overhead? BTW, here's the traceback we get. As you probably can guess, something called os.urandom before we closed all file descriptors in the daemonizing code and it then failed when os.urandom tried to use the cached fd. Traceback (most recent call last): File "/opt/race/share/sw/common/bin/dpmd", line 27, in ? dpmd().run() File "Linux/CommandLineApp.py", line 336, in run File "Linux/daemonbase.py", line 324, in main File "Linux/server.py", line 61, in addServices File "Linux/dpmd.py", line 293, in __init__ File "Linux/threadutils.py", line 44, in start File "Linux/xmlrpcd.py", line 165, in createThread File "Linux/threadutils.py", line 126, in __init__ File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 423, in NamedTemporaryFile dir = gettempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 262, in gettempdir tempdir = _get_default_tempdir() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 185, in _get_default_tempdir namer = _RandomNameSequence() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/t empfile.py", line 121, in __init__ self.rng = _Random() File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 96, in __init__ self.seed(x) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/r andom.py", line 110, in seed a = long(_hexlify(_urandom(16)), 16) File "/opt/race/share/sw/os/Linux_2.4_i686/python/lib/python2.4/ os.py", line 728, in urandom bytes += read(_urandomfd, n - len(bytes)) OSError : [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 11:04 Message: Logged In: YES user_id=81797 The child is a copy of the parent. Therefore, if in the parent you open a few file descriptors, those are the ones you should close in the child. That is exactly what I've done in the past when I forked a child, and it has worked very well. I suspect Stevens would make an exception to his guideline in the event that closing a file descriptor results in library routine failures. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 09:27 Message: Logged In: YES user_id=110477 Unfortunately, catching exceptions is not sufficient - the file descriptor may have been reassigned. Fortunately in my case, to a socket which raised ENOSYS, but if it had been a normal file, this would have been much harder to trace because reading from it would cause weird errors for readers of the reassigned fd without triggering an exception in os.urandom() itself. As for not closing file descriptors you haven't opened yourself, if the process is the result of a vfork/exec (in my case Python processes started by a cluster manager, sort of like init), the child process has no clue what file descriptors, sockets or the like it has inherited from its parent process, and the safest course is to close them all. Indeed, that's what W. Richard Stevens recommends in "Advanced Programming for the UNIX environment". As far as I can tell, os.urandom() is used mostly to seed the RNG in random.py, and thus is not a high-drequency operation. It is going to be very hard to document this adequately for coders to defend against - in my case, the problem was being triggered by os.tempnam() from within Webware's PSP compiler. There are so many functions that depend on random (sometimes in non-obvious ways), you can't flag them all so their users know they should use urandomcleanup. One possible solution would be for os.py to offer a go_daemon() function that implements the fd closing, signal masking, process group and terminal disassociation required by true daemons. This function could take care of internal book-keeping like calling urandomcleanup. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 09:20 Message: Logged In: YES user_id=81797 Yeah, I was thinking the same thing. It doesn't address the consumed file handle, but it does address the "robustness" issue. It complicates the code, but should work. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-06 09:11 Message: Logged In: YES user_id=21627 To add robustness, it would be possible to catch read errors from _urandomfd, and try reopening it if it got somehow closed. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-06 05:11 Message: Logged In: YES user_id=81797 Just providing some feedback: I'm able to reproduce this. Importing random will cause this file descriptor to be called. Opening urandom on every call could lead to unacceptable syscall overhead for some. Perhaps there should be a "urandomcleanup" method that closes the file descriptor, and then random could get the bytes from urandom(), and clean up after itself? Personally, I only clean up the file descriptors I have allocated when I fork a new process. On the one hand I agree with you about sucking up a fd in the standard library, but on the other hand I'm thinking that you just shouldn't be closing file descriptors for stuff you'll be needing. That's my two cents on this bug. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2005-04-06 03:06 Message: Logged In: YES user_id=110477 There are many modules that have a dependency on random, for instance os.tempnam(), and a program could well inadvertently use it before closing file descriptors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&group_id=5470 From noreply at sourceforge.net Tue Jul 5 06:35:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jul 2005 21:35:28 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-04 22: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=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 13:18:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 04:18:19 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-05 05:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-05 12:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 15:17:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 06:17:10 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-04 22:35 Message generated for change (Comment added) made by skyrush You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:17 Message: Logged In: YES user_id=738814 So sorry! Yes, os.utime(). And I thought I attached the file - trying again... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 05:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 15:19:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 06:19:00 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-04 22:35 Message generated for change (Comment added) made by skyrush You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:18 Message: Logged In: YES user_id=738814 Oh, guess it's not enough to fill in the upload type-in field - that pesky little checkbox needs to be checked. Sneaky... OK, it should be attached now. ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:17 Message: Logged In: YES user_id=738814 So sorry! Yes, os.utime(). And I thought I attached the file - trying again... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 05:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 15:27:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 06:27:22 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-05 05:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-05 14:27 Message: Logged In: YES user_id=6656 Can you try the attached patch? ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 14:18 Message: Logged In: YES user_id=738814 Oh, guess it's not enough to fill in the upload type-in field - that pesky little checkbox needs to be checked. Sneaky... OK, it should be attached now. ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 14:17 Message: Logged In: YES user_id=738814 So sorry! Yes, os.utime(). And I thought I attached the file - trying again... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 12:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 16:08:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 07:08:13 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-04 22:35 Message generated for change (Comment added) made by skyrush You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Joe Peterson (skyrush) Date: 2005-07-05 08:08 Message: Logged In: YES user_id=738814 I will have to get the python source - using binary right now, but I'll try the patch and let you know. Might this not be a larger problem in Python, however? Or is it normal for non-caught errors in C modules to be able to confuse the interpreter? For example, someone from the mailing list submitted the following result on Python 2.2, which shows a different thing happening, but clearly also strangeness, given that the passed argument *is* a tuple: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> os.utime("foo_test_file", (0, float(sys.maxint+1))) Traceback (most recent call last): File "", line 1, in ? TypeError: utime() arg 2 must be a tuple (atime, mtime) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 07:27 Message: Logged In: YES user_id=6656 Can you try the attached patch? ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:18 Message: Logged In: YES user_id=738814 Oh, guess it's not enough to fill in the upload type-in field - that pesky little checkbox needs to be checked. Sneaky... OK, it should be attached now. ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:17 Message: Logged In: YES user_id=738814 So sorry! Yes, os.utime(). And I thought I attached the file - trying again... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 05:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 16:11:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 07:11:25 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-05 05:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-05 15:11 Message: Logged In: YES user_id=6656 > Might this not be a larger problem in Python, however? No, not really. > Or > is it normal for non-caught errors in C modules to be able > to confuse the interpreter? Yes. (I don't care about 2.2 any more, sorry). ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 15:08 Message: Logged In: YES user_id=738814 I will have to get the python source - using binary right now, but I'll try the patch and let you know. Might this not be a larger problem in Python, however? Or is it normal for non-caught errors in C modules to be able to confuse the interpreter? For example, someone from the mailing list submitted the following result on Python 2.2, which shows a different thing happening, but clearly also strangeness, given that the passed argument *is* a tuple: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> os.utime("foo_test_file", (0, float(sys.maxint+1))) Traceback (most recent call last): File "", line 1, in ? TypeError: utime() arg 2 must be a tuple (atime, mtime) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 14:27 Message: Logged In: YES user_id=6656 Can you try the attached patch? ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 14:18 Message: Logged In: YES user_id=738814 Oh, guess it's not enough to fill in the upload type-in field - that pesky little checkbox needs to be checked. Sneaky... OK, it should be attached now. ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 14:17 Message: Logged In: YES user_id=738814 So sorry! Yes, os.utime(). And I thought I attached the file - trying again... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 12:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 16:11:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 07:11:49 -0700 Subject: [ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding" Message-ID: Bugs item #1232768, was opened at 2005-07-05 14:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 Please note that this 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: Matt Smart (mcsmart) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in online docs under "5.3 Pure Embedding" Initial Comment: I'm looking at the "5.3 Pure Embedding" page: http://python.org/doc/2.4.1/ext/pure-embedding.html 1. pFunc = PyDict_GetItemString(pDict, argv[2]); - /* pFun: Borrowed reference */ + /* pFunc: Borrowed reference */ 2. The code snippet in the section starting with "After initializing the interpreter," does not follow the code in the example. It uses PyObject_GetAttrString() instead of PyObject_GetItemString(), which creates a new reference instead of borrowing one, and therefore needs a Py_XDEREF(pFunc) call that is also not in the initial example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 From noreply at sourceforge.net Tue Jul 5 17:08:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 08:08:30 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-04 22:35 Message generated for change (Comment added) made by skyrush You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Joe Peterson (skyrush) Date: 2005-07-05 09:08 Message: Logged In: YES user_id=738814 I tried the patch (actually on 2.4.1 source), and it works. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 08:11 Message: Logged In: YES user_id=6656 > Might this not be a larger problem in Python, however? No, not really. > Or > is it normal for non-caught errors in C modules to be able > to confuse the interpreter? Yes. (I don't care about 2.2 any more, sorry). ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 08:08 Message: Logged In: YES user_id=738814 I will have to get the python source - using binary right now, but I'll try the patch and let you know. Might this not be a larger problem in Python, however? Or is it normal for non-caught errors in C modules to be able to confuse the interpreter? For example, someone from the mailing list submitted the following result on Python 2.2, which shows a different thing happening, but clearly also strangeness, given that the passed argument *is* a tuple: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> os.utime("foo_test_file", (0, float(sys.maxint+1))) Traceback (most recent call last): File "", line 1, in ? TypeError: utime() arg 2 must be a tuple (atime, mtime) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 07:27 Message: Logged In: YES user_id=6656 Can you try the attached patch? ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:18 Message: Logged In: YES user_id=738814 Oh, guess it's not enough to fill in the upload type-in field - that pesky little checkbox needs to be checked. Sneaky... OK, it should be attached now. ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:17 Message: Logged In: YES user_id=738814 So sorry! Yes, os.utime(). And I thought I attached the file - trying again... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 05:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 17:23:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 08:23:33 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-05 05:35 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) >Assigned to: Michael Hudson (mwh) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-05 16:23 Message: Logged In: YES user_id=6656 OK, this is fixed in Misc/NEWS revision 1.1310 Modules/posixmodule.c revision 2.337 Thanks for the report and the test! ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 16:08 Message: Logged In: YES user_id=738814 I tried the patch (actually on 2.4.1 source), and it works. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 15:11 Message: Logged In: YES user_id=6656 > Might this not be a larger problem in Python, however? No, not really. > Or > is it normal for non-caught errors in C modules to be able > to confuse the interpreter? Yes. (I don't care about 2.2 any more, sorry). ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 15:08 Message: Logged In: YES user_id=738814 I will have to get the python source - using binary right now, but I'll try the patch and let you know. Might this not be a larger problem in Python, however? Or is it normal for non-caught errors in C modules to be able to confuse the interpreter? For example, someone from the mailing list submitted the following result on Python 2.2, which shows a different thing happening, but clearly also strangeness, given that the passed argument *is* a tuple: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> os.utime("foo_test_file", (0, float(sys.maxint+1))) Traceback (most recent call last): File "", line 1, in ? TypeError: utime() arg 2 must be a tuple (atime, mtime) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 14:27 Message: Logged In: YES user_id=6656 Can you try the attached patch? ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 14:18 Message: Logged In: YES user_id=738814 Oh, guess it's not enough to fill in the upload type-in field - that pesky little checkbox needs to be checked. Sneaky... OK, it should be attached now. ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 14:17 Message: Logged In: YES user_id=738814 So sorry! Yes, os.utime(). And I thought I attached the file - trying again... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 12:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 17:33:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 08:33:03 -0700 Subject: [ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback Message-ID: Bugs item #1232517, was opened at 2005-07-04 22:35 Message generated for change (Comment added) made by skyrush You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 Please note that this message 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: Joe Peterson (skyrush) Assigned to: Michael Hudson (mwh) Summary: OverflowError in time.utime() causes strange traceback Initial Comment: When time.utime() is called with a number larger than an int, it will fail, but the traceback will not show the line containing the utime() call. Instead, the error will be reported sometime later, depending on the conditions. In the attached example (note the file "foo_test_file" must exist first), a number one larger than maxint is passed, causing the following error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted My original discovery of this problem was in a larger program, and in this original case, I was generating the large integer via a call to mktime_tz in the rfc822 module in which an out-of-range timezone value was used. The call was near the end of a "for" block, and the OverflowError was reported as coming from the for statement of the block itself (which did not make sense). I produced a small test case, which moved the reported error to "garbage collection". Thanks to some folks on the python mailing list for helping to further simplify the test case. ---------------------------------------------------------------------- >Comment By: Joe Peterson (skyrush) Date: 2005-07-05 09:33 Message: Logged In: YES user_id=738814 Cool - glad to be of help! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 09:23 Message: Logged In: YES user_id=6656 OK, this is fixed in Misc/NEWS revision 1.1310 Modules/posixmodule.c revision 2.337 Thanks for the report and the test! ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 09:08 Message: Logged In: YES user_id=738814 I tried the patch (actually on 2.4.1 source), and it works. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 08:11 Message: Logged In: YES user_id=6656 > Might this not be a larger problem in Python, however? No, not really. > Or > is it normal for non-caught errors in C modules to be able > to confuse the interpreter? Yes. (I don't care about 2.2 any more, sorry). ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 08:08 Message: Logged In: YES user_id=738814 I will have to get the python source - using binary right now, but I'll try the patch and let you know. Might this not be a larger problem in Python, however? Or is it normal for non-caught errors in C modules to be able to confuse the interpreter? For example, someone from the mailing list submitted the following result on Python 2.2, which shows a different thing happening, but clearly also strangeness, given that the passed argument *is* a tuple: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> os.utime("foo_test_file", (0, float(sys.maxint+1))) Traceback (most recent call last): File "", line 1, in ? TypeError: utime() arg 2 must be a tuple (atime, mtime) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 07:27 Message: Logged In: YES user_id=6656 Can you try the attached patch? ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:18 Message: Logged In: YES user_id=738814 Oh, guess it's not enough to fill in the upload type-in field - that pesky little checkbox needs to be checked. Sneaky... OK, it should be attached now. ---------------------------------------------------------------------- Comment By: Joe Peterson (skyrush) Date: 2005-07-05 07:17 Message: Logged In: YES user_id=738814 So sorry! Yes, os.utime(). And I thought I attached the file - trying again... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-05 05:18 Message: Logged In: YES user_id=6656 You mean os.utime (gawd, that confused me) and there's no attached file... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470 From noreply at sourceforge.net Tue Jul 5 20:31:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 11:31:26 -0700 Subject: [ python-Bugs-1232947 ] non-admin install may fail (win xp pro) Message-ID: Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pvrijlandt (pvrijlandt) Assigned to: Nobody/Anonymous (nobody) Summary: non-admin install may fail (win xp pro) Initial Comment: concerns: python 2.4.1 msi When trying to do a non-admin install on Windows XP Pro, the installer probably tries to make shortcuts in a non-accessible directory. The status-window is displaying: creating shortcuts A messagebox appears and says the installer lacks priveliges on a certain directory: please try again as an administrator, (which i am obviously not). The cancel-option now leads to a rollback of the installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 From noreply at sourceforge.net Wed Jul 6 00:14:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 15:14:20 -0700 Subject: [ python-Bugs-1233049 ] openssl-0.9.8 requires _ssl.mak change Message-ID: Bugs item #1233049, was opened at 2005-07-05 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=1233049&group_id=5470 Please note that this 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: 3rd Party Status: Open Resolution: None Priority: 5 Submitted By: Alan Meyer (vrmeyer) Assigned to: Nobody/Anonymous (nobody) Summary: openssl-0.9.8 requires _ssl.mak change Initial Comment: When building _ssl.pyd for Windows I downloaded the latest openssl (0.9.8) released today, July 5, 2005. After building the openssl libraries successfully I downloaded the source code for Python 2.4.1 and ran PCBuild/_ssl.mak. It failed to link four Windows functions in cryptlib.obj in libeay32.lib in openssl. To fix this, "user32.lib" must be added to the definition of "LIBS" in _ssl.mak. We have not tested further, deciding to fallback to an earlier version of openssl since, clearly this latest version had not yet been tested with Python and we are building this for production code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233049&group_id=5470 From noreply at sourceforge.net Wed Jul 6 07:14:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 22:14:43 -0700 Subject: [ python-Bugs-1233049 ] openssl-0.9.8 requires _ssl.mak change Message-ID: Bugs item #1233049, was opened at 2005-07-06 00:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233049&group_id=5470 Please note that this 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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Alan Meyer (vrmeyer) Assigned to: Nobody/Anonymous (nobody) Summary: openssl-0.9.8 requires _ssl.mak change Initial Comment: When building _ssl.pyd for Windows I downloaded the latest openssl (0.9.8) released today, July 5, 2005. After building the openssl libraries successfully I downloaded the source code for Python 2.4.1 and ran PCBuild/_ssl.mak. It failed to link four Windows functions in cryptlib.obj in libeay32.lib in openssl. To fix this, "user32.lib" must be added to the definition of "LIBS" in _ssl.mak. We have not tested further, deciding to fallback to an earlier version of openssl since, clearly this latest version had not yet been tested with Python and we are building this for production code. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 07:14 Message: Logged In: YES user_id=21627 This is indeed not a bug. The build process on Windows is only meant to work with the versions of packages listed in PCbuild/readme.txt, which means OpenSSL 0.9.7d. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233049&group_id=5470 From noreply at sourceforge.net Wed Jul 6 07:16:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 22:16:24 -0700 Subject: [ python-Bugs-1232947 ] non-admin install may fail (win xp pro) Message-ID: Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pvrijlandt (pvrijlandt) Assigned to: Nobody/Anonymous (nobody) Summary: non-admin install may fail (win xp pro) Initial Comment: concerns: python 2.4.1 msi When trying to do a non-admin install on Windows XP Pro, the installer probably tries to make shortcuts in a non-accessible directory. The status-window is displaying: creating shortcuts A messagebox appears and says the installer lacks priveliges on a certain directory: please try again as an administrator, (which i am obviously not). The cancel-option now leads to a rollback of the installation. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 07:16 Message: Logged In: YES user_id=21627 It works fine for me... Can you please install with msiexec /i python-2.4.1.msi /l*v python.log and attach a zipped version of python.log? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&group_id=5470 From noreply at sourceforge.net Wed Jul 6 07:17:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 22:17:59 -0700 Subject: [ python-Bugs-1231488 ] chr() returns ? when input > 127 in OS X Message-ID: Bugs item #1231488, was opened at 2005-07-02 15:52 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231488&group_id=5470 Please note that this 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: Invalid Priority: 5 Submitted By: Craig Howard (craighoward) Assigned to: Nobody/Anonymous (nobody) Summary: chr() returns ? when input > 127 in OS X Initial Comment: When using macpython in OS X Tiger, chr(130) should return an "e" with an accent symbol above it. Instead it returns a "?", as it does with any number above 127. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 07:17 Message: Logged In: YES user_id=21627 I'm pretty sure it is like mwh suggest - this is not a bug in Python, but just Terminal.app which displays single bytes > 127 as question marks if it operates in UTF-8 mode. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-03 17:01 Message: Logged In: YES user_id=6656 I have a hard time believing this report at face value. How are you determining that chr(130) is "?"? Are you sure that it's not just being *printed* that way? Also, I don't see why you think chr(130) should be LATIN SMALL LETTER E WITH ACUTE. That character is 142 in the mac roman encoding and 233 in the latin-1/iso8859-1 encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231488&group_id=5470 From noreply at sourceforge.net Wed Jul 6 07:20:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 22:20:44 -0700 Subject: [ python-Bugs-1230161 ] Build failure Message-ID: Bugs item #1230161, was opened at 2005-06-30 08:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230161&group_id=5470 Please note that this 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: L.M (ceramond) Assigned to: Nobody/Anonymous (nobody) Summary: Build failure Initial Comment: ./configure + make fails with various errors on FreeBSD 4.11-RELEASE case $MAKEFLAGS in *-s*) CC='gcc -pthread' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os *** Error code 1 If I run "make" again, it stops with this, instead, I found it strange because "pwd.so" isn't ready yet. case $MAKEFLAGS in *-s*) CC='gcc -pthread' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 1184, in ? main() File "./setup.py", line 1178, in main scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', File "/home/mondo/Python-2.4.1/Lib/distutils/core.py", line 123, in setup dist.parse_config_files() File "/home/mondo/Python-2.4.1/Lib/distutils/dist.py", line 339, in parse_config_files filenames = self.find_config_files() File "/home/mondo/Python-2.4.1/Lib/distutils/dist.py", line 302, in find_config_files check_environ() File "/home/mondo/Python-2.4.1/Lib/distutils/util.py", line 155, in check_environ import pwd ImportError: No module named pwd *** Error code 1 I've tried "make clean" + retry, giving --prefix=so-and-so to ./configure, and some other things without success. I have already built exactly same Python source on this server several weeks ago (in a different directory), and do not understand why it's failing, now. (Possibly, admin updated something causing build process to fail...) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 07:20 Message: Logged In: YES user_id=21627 The pwd module is only used if HOME isn't set. Why is HOME not set on your system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230161&group_id=5470 From noreply at sourceforge.net Wed Jul 6 07:28:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jul 2005 22:28:37 -0700 Subject: [ python-Bugs-1223976 ] error locale.getlocale() with LANGUAGE=eu_ES Message-ID: Bugs item #1223976, was opened at 2005-06-20 10:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zunbeltz Izaola (zunbeltz) Assigned to: Nobody/Anonymous (nobody) Summary: error locale.getlocale() with LANGUAGE=eu_ES Initial Comment: I had sumited this bug (id 1177674) and it has been closed becouse my bad explanation. My locale is set to LANGUAGE=eu_ES This is what i get in the interpreter Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() (None, None) >>> locale.setlocale(locale.LC_ALL, '') 'eu_ES' >>> >>> locale.getlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 365, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 07:28 Message: Logged In: YES user_id=21627 What do you need locale.getlocale() for? If it is to determine the encoding, I recommend to use locale.getpreferredencoding() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 From noreply at sourceforge.net Wed Jul 6 16:13:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jul 2005 07:13:30 -0700 Subject: [ python-Bugs-1230161 ] Build failure Message-ID: Bugs item #1230161, was opened at 2005-06-30 06:27 Message generated for change (Settings changed) made by ceramond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230161&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: L.M (ceramond) Assigned to: Nobody/Anonymous (nobody) Summary: Build failure Initial Comment: ./configure + make fails with various errors on FreeBSD 4.11-RELEASE case $MAKEFLAGS in *-s*) CC='gcc -pthread' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os *** Error code 1 If I run "make" again, it stops with this, instead, I found it strange because "pwd.so" isn't ready yet. case $MAKEFLAGS in *-s*) CC='gcc -pthread' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 1184, in ? main() File "./setup.py", line 1178, in main scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', File "/home/mondo/Python-2.4.1/Lib/distutils/core.py", line 123, in setup dist.parse_config_files() File "/home/mondo/Python-2.4.1/Lib/distutils/dist.py", line 339, in parse_config_files filenames = self.find_config_files() File "/home/mondo/Python-2.4.1/Lib/distutils/dist.py", line 302, in find_config_files check_environ() File "/home/mondo/Python-2.4.1/Lib/distutils/util.py", line 155, in check_environ import pwd ImportError: No module named pwd *** Error code 1 I've tried "make clean" + retry, giving --prefix=so-and-so to ./configure, and some other things without success. I have already built exactly same Python source on this server several weeks ago (in a different directory), and do not understand why it's failing, now. (Possibly, admin updated something causing build process to fail...) ---------------------------------------------------------------------- >Comment By: L.M (ceramond) Date: 2005-07-06 14:13 Message: Logged In: YES user_id=1305168 Thank you for the info. "export HOME" soplved the problem. HOME wasn't exported because I was compiling on shared hosting environment, and the host doesn't set normal env variables. I set HOME (and some other env var), but didn't export them. And that caused the build failure. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 05:20 Message: Logged In: YES user_id=21627 The pwd module is only used if HOME isn't set. Why is HOME not set on your system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230161&group_id=5470 From noreply at sourceforge.net Wed Jul 6 18:03:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jul 2005 09:03:07 -0700 Subject: [ python-Bugs-1233578 ] Pickle protocols 1, 2 can't handle "inf" floats. Message-ID: Bugs item #1233578, was opened at 2005-07-06 10:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233578&group_id=5470 Please note that this message 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: Pickle protocols 1, 2 can't handle "inf" floats. Initial Comment: Python 2.4.1 on an AMD64 system. The pickle module barfs with a "SystemError: frexp() result out of range" if an "inf" float value is pickled with pickle protocol 1 or 2. It works fine with the old protocol 0. Minimal test case: >>> import pickle >>> o = 2e308 >>> print o inf >>> pickle.dumps(o, protocol=0) 'Finf\n.' >>> >>> pickle.dumps(o, protocol=1) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/usr/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range >>> >>> pickle.dumps(o, protocol=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/usr/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233578&group_id=5470 From noreply at sourceforge.net Wed Jul 6 18:06:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jul 2005 09:06:43 -0700 Subject: [ python-Bugs-1233578 ] Pickle protocols 1, 2 can't handle "inf" floats. Message-ID: Bugs item #1233578, was opened at 2005-07-06 17:03 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233578&group_id=5470 Please note that this message 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: Charles (melicertes) >Assigned to: Michael Hudson (mwh) Summary: Pickle protocols 1, 2 can't handle "inf" floats. Initial Comment: Python 2.4.1 on an AMD64 system. The pickle module barfs with a "SystemError: frexp() result out of range" if an "inf" float value is pickled with pickle protocol 1 or 2. It works fine with the old protocol 0. Minimal test case: >>> import pickle >>> o = 2e308 >>> print o inf >>> pickle.dumps(o, protocol=0) 'Finf\n.' >>> >>> pickle.dumps(o, protocol=1) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/usr/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range >>> >>> pickle.dumps(o, protocol=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/usr/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-06 17:06 Message: Logged In: YES user_id=6656 This is fixed in CVS. (And also the third time I've closed this bug in the last fortnight! FFS guys!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233578&group_id=5470 From noreply at sourceforge.net Wed Jul 6 19:02:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jul 2005 10:02:21 -0700 Subject: [ python-Bugs-1233049 ] openssl-0.9.8 requires _ssl.mak change Message-ID: Bugs item #1233049, was opened at 2005-07-05 22:14 Message generated for change (Comment added) made by vrmeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233049&group_id=5470 Please note that this 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: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alan Meyer (vrmeyer) Assigned to: Nobody/Anonymous (nobody) Summary: openssl-0.9.8 requires _ssl.mak change Initial Comment: When building _ssl.pyd for Windows I downloaded the latest openssl (0.9.8) released today, July 5, 2005. After building the openssl libraries successfully I downloaded the source code for Python 2.4.1 and ran PCBuild/_ssl.mak. It failed to link four Windows functions in cryptlib.obj in libeay32.lib in openssl. To fix this, "user32.lib" must be added to the definition of "LIBS" in _ssl.mak. We have not tested further, deciding to fallback to an earlier version of openssl since, clearly this latest version had not yet been tested with Python and we are building this for production code. ---------------------------------------------------------------------- >Comment By: Alan Meyer (vrmeyer) Date: 2005-07-06 17:02 Message: Logged In: YES user_id=338015 I agree it's not a bug but didn't see any way to indicate it as an enhancement in the SourceForge interface. I recorded it simply as a note to whoever supports ssl in Python since they will eventually want to upgrade to later versions of openssl, and thought my note might save them a bit of trouble. Thanks for your support of Python. Regards, Alan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 05:14 Message: Logged In: YES user_id=21627 This is indeed not a bug. The build process on Windows is only meant to work with the versions of packages listed in PCbuild/readme.txt, which means OpenSSL 0.9.7d. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233049&group_id=5470 From noreply at sourceforge.net Wed Jul 6 21:34:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jul 2005 12:34:39 -0700 Subject: [ python-Bugs-1233049 ] openssl-0.9.8 requires _ssl.mak change Message-ID: Bugs item #1233049, was opened at 2005-07-06 00:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233049&group_id=5470 Please note that this 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: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alan Meyer (vrmeyer) Assigned to: Nobody/Anonymous (nobody) Summary: openssl-0.9.8 requires _ssl.mak change Initial Comment: When building _ssl.pyd for Windows I downloaded the latest openssl (0.9.8) released today, July 5, 2005. After building the openssl libraries successfully I downloaded the source code for Python 2.4.1 and ran PCBuild/_ssl.mak. It failed to link four Windows functions in cryptlib.obj in libeay32.lib in openssl. To fix this, "user32.lib" must be added to the definition of "LIBS" in _ssl.mak. We have not tested further, deciding to fallback to an earlier version of openssl since, clearly this latest version had not yet been tested with Python and we are building this for production code. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 21:34 Message: Logged In: YES user_id=21627 Thanks, I have added a remark into readme.txt 1.59. ---------------------------------------------------------------------- Comment By: Alan Meyer (vrmeyer) Date: 2005-07-06 19:02 Message: Logged In: YES user_id=338015 I agree it's not a bug but didn't see any way to indicate it as an enhancement in the SourceForge interface. I recorded it simply as a note to whoever supports ssl in Python since they will eventually want to upgrade to later versions of openssl, and thought my note might save them a bit of trouble. Thanks for your support of Python. Regards, Alan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 07:14 Message: Logged In: YES user_id=21627 This is indeed not a bug. The build process on Windows is only meant to work with the versions of packages listed in PCbuild/readme.txt, which means OpenSSL 0.9.7d. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233049&group_id=5470 From noreply at sourceforge.net Wed Jul 6 23:36:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jul 2005 14:36:18 -0700 Subject: [ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix Message-ID: Bugs item #1233785, was opened at 2005-07-07 09:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 Please note that this 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: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 From noreply at sourceforge.net Thu Jul 7 00:08:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jul 2005 15:08:18 -0700 Subject: [ python-Bugs-1233799 ] tkFileDialog.askopen... fails when dir="" Message-ID: Bugs item #1233799, was opened at 2005-07-06 15: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=1233799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.askopen... fails when dir="" Initial Comment: The following simple code fails on MacOS X 10.3 running the built- in python 2.3 and Aqua Tcl/Tk 8.4.9: import Tkinter import tkFileDialog root = Tkinter.Tk() newPath = tkFileDialog.askopenfilename( initialdir = "", ) The error is: Traceback (most recent call last): File "tkFileDialog_askopen bug.py", line 5, in ? newPath = tkFileDialog.askopenfilename( File "/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename return Open(**options).show() File "/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/lib-tk/tkCommonDialog.py", line 52, in show s = w.tk.call(self.command, *w._options(self.options)) _tkinter.TclError: bad directory "" The same code runs fine on unix Python 2.2.3 with unknown tcl/tk and on and unix Python 2.4.1 with tcl/tk 8.4.9. it starts out in the user's home directory as I'd expect. Mind you, I know I can use None or not specify the initialdir argument. But in my code it's a string that *might* be empty. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470 From noreply at sourceforge.net Thu Jul 7 10:46:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 01:46:21 -0700 Subject: [ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix Message-ID: Bugs item #1233785, was opened at 2005-07-06 23:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 Please note that this 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: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 10:46 Message: Logged In: YES user_id=1188172 What makes you think that? I tried it on Windows XP, in a cmd.exe session. I could enter, for example, an ? (umlauted u), which in the resulting string came out encoded as \x81, as is correct in the encoding used by the console window, namely cp850. I could then convert this to latin1 by using s.decode(sys.stdin.encoding).encode("latin-1"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 From noreply at sourceforge.net Thu Jul 7 11:18:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 02:18:52 -0700 Subject: [ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix Message-ID: Bugs item #1233785, was opened at 2005-07-07 09:36 Message generated for change (Comment added) made by esrever_otua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 Please note that this 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: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. ---------------------------------------------------------------------- >Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 21:18 Message: Logged In: YES user_id=567623 I think that, because I've read the source, and getpass.getpass() uses msvcrt.getch() on Windows, which doesn't support anything at all above ASCII 255. Also because I have a bug report pending against one of the projects that I maintain from a user that is experiencing a problem because of exactly this issue. See: https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935 Also, I call shenanigans on your claim of successfully inputting an umlaut-u into getpass.getpass(); this character can *theoretically* be input, as it's below ASCII 255, but in practice I can neither input it directly, nor COPY+PASTE it from the clipboard on my WinXP SP2 with Python 2.4.1 installed. Finally, regardless of whether "?" works or not, other characters that live solely in unicode, such as "?" most certainly do not (and never will) work (not even theoretically). Regards, D ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 20:46 Message: Logged In: YES user_id=1188172 What makes you think that? I tried it on Windows XP, in a cmd.exe session. I could enter, for example, an ? (umlauted u), which in the resulting string came out encoded as \x81, as is correct in the encoding used by the console window, namely cp850. I could then convert this to latin1 by using s.decode(sys.stdin.encoding).encode("latin-1"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 From noreply at sourceforge.net Thu Jul 7 12:01:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 03:01:13 -0700 Subject: [ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix Message-ID: Bugs item #1233785, was opened at 2005-07-06 23:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 Please note that this 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: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 12:01 Message: Logged In: YES user_id=1188172 First of all, don't accuse me of lying. If I wanted to lie professionally, I would have become politician, not programmer. I'm German, and using a German keyboard layout which does have the ?, so it can be perfectly input. Your problem is that you cannot input characters which don't directly create keycodes on the keyboard, but must be copied to the console in some way. In python-dev, you said that msvcrt.getch() would have to call _getch() a second time in the case that it returns 0x00 or 0xe0 the first time and/or return a Unicode string. First, the documentation for _getch() says that this is a special case for arrow and function keys (such as F1 or ). These keys don't have a representation in any character set, as they are control keys, so how would you represent them as Unicode? Second: In my console, pressing F7 yields the return values "\x00" and "A". When the 0x00/0xe0 read the first time is secretly swallowed, the user of msvcrt.getch() can't know whether the user pressed "A" or F7. That said, the behaviour of getch() is documented and correct. But how does that all help you with your original problem, which is that _getch() doesn't help you with Alt+XXXX sequences or console window Copy-Paste? In my understanding _getch() only works with characters directly input to the console. Sorry, but then this is not a Python problem but a Windows one. ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 11:18 Message: Logged In: YES user_id=567623 I think that, because I've read the source, and getpass.getpass() uses msvcrt.getch() on Windows, which doesn't support anything at all above ASCII 255. Also because I have a bug report pending against one of the projects that I maintain from a user that is experiencing a problem because of exactly this issue. See: https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935 Also, I call shenanigans on your claim of successfully inputting an umlaut-u into getpass.getpass(); this character can *theoretically* be input, as it's below ASCII 255, but in practice I can neither input it directly, nor COPY+PASTE it from the clipboard on my WinXP SP2 with Python 2.4.1 installed. Finally, regardless of whether "?" works or not, other characters that live solely in unicode, such as "?" most certainly do not (and never will) work (not even theoretically). Regards, D ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 10:46 Message: Logged In: YES user_id=1188172 What makes you think that? I tried it on Windows XP, in a cmd.exe session. I could enter, for example, an ? (umlauted u), which in the resulting string came out encoded as \x81, as is correct in the encoding used by the console window, namely cp850. I could then convert this to latin1 by using s.decode(sys.stdin.encoding).encode("latin-1"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 From noreply at sourceforge.net Thu Jul 7 12:15:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 03:15:55 -0700 Subject: [ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix Message-ID: Bugs item #1233785, was opened at 2005-07-07 09:36 Message generated for change (Comment added) made by esrever_otua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 Please note that this 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: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. ---------------------------------------------------------------------- >Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 22:15 Message: Logged In: YES user_id=567623 Right. I've had enough of this nonsense, listen carefully: as English isn't your first language I'll make this as simple as possible: 1) I didn't come here to start a flame war, but rather to point out a genuine deficiency in the Windows getpass, compared to the *nix version. 2) You didn't lie, and *I didn't accuse you of that*, but rather pointed out that all was not correct or complete in your assertion. *I* was right, as you carefully neglected to mention that you're using a native keyboard, with an NLS system that puts ? below ASCII 127 in your local codepage 3) getpass.getpass(), when called on *nix, allows me to input '?' and every other character under the sun. When called on Windows, *it does not*. This Means Complex Passwords With getpass() Aren't Portable. End Of Story. It Is Undocumented. This Is A Bug. 4) Yes the problem isn't that getch() isn't doing what it should, it is that getch() is the *wrong function to use* in order to gain parity with the *nix version. 5) Finally, you seem hell-bent on ignoring what I've written. I was wrong about getch() behaviour on python-dev, but That Isn't The Problem, which is why *I* didn't mention it in this initial bug-report. My assertion below that getch() won't get anything above ASCII 255 is *completely accurate*. It is the Wrong Function To Use. This Is A Bug In Getpass. 6) Finally, Finally, please read this and understand: As per the initial bug-report, the problem is that getpass on Windows is limited in ways that getpass on *nix isn't. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 22:01 Message: Logged In: YES user_id=1188172 First of all, don't accuse me of lying. If I wanted to lie professionally, I would have become politician, not programmer. I'm German, and using a German keyboard layout which does have the ?, so it can be perfectly input. Your problem is that you cannot input characters which don't directly create keycodes on the keyboard, but must be copied to the console in some way. In python-dev, you said that msvcrt.getch() would have to call _getch() a second time in the case that it returns 0x00 or 0xe0 the first time and/or return a Unicode string. First, the documentation for _getch() says that this is a special case for arrow and function keys (such as F1 or ). These keys don't have a representation in any character set, as they are control keys, so how would you represent them as Unicode? Second: In my console, pressing F7 yields the return values "\x00" and "A". When the 0x00/0xe0 read the first time is secretly swallowed, the user of msvcrt.getch() can't know whether the user pressed "A" or F7. That said, the behaviour of getch() is documented and correct. But how does that all help you with your original problem, which is that _getch() doesn't help you with Alt+XXXX sequences or console window Copy-Paste? In my understanding _getch() only works with characters directly input to the console. Sorry, but then this is not a Python problem but a Windows one. ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 21:18 Message: Logged In: YES user_id=567623 I think that, because I've read the source, and getpass.getpass() uses msvcrt.getch() on Windows, which doesn't support anything at all above ASCII 255. Also because I have a bug report pending against one of the projects that I maintain from a user that is experiencing a problem because of exactly this issue. See: https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935 Also, I call shenanigans on your claim of successfully inputting an umlaut-u into getpass.getpass(); this character can *theoretically* be input, as it's below ASCII 255, but in practice I can neither input it directly, nor COPY+PASTE it from the clipboard on my WinXP SP2 with Python 2.4.1 installed. Finally, regardless of whether "?" works or not, other characters that live solely in unicode, such as "?" most certainly do not (and never will) work (not even theoretically). Regards, D ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 20:46 Message: Logged In: YES user_id=1188172 What makes you think that? I tried it on Windows XP, in a cmd.exe session. I could enter, for example, an ? (umlauted u), which in the resulting string came out encoded as \x81, as is correct in the encoding used by the console window, namely cp850. I could then convert this to latin1 by using s.decode(sys.stdin.encoding).encode("latin-1"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 From noreply at sourceforge.net Thu Jul 7 12:29:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 03:29:17 -0700 Subject: [ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix Message-ID: Bugs item #1233785, was opened at 2005-07-06 23:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 Please note that this 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: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 12:29 Message: Logged In: YES user_id=1188172 Okay. This isn't menat to attempt a flamewar, but rather find out what can be done to help you (and, thank you very much for making it simple extra for me, I would have preferred the simple version even if I was a native speaker). You're right that this bug report is about getpass's portability, I had a bit lost track of this. Since you posted the link to your tracker in your previous comment, I somehow linked this to here. I have only two questions left. 1) Do you know another function in the MS API that allows reading a character from the console without displaying it? 2) How do you input your characters under the sun on Unix? Can you do this on a text console, too? ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 12:15 Message: Logged In: YES user_id=567623 Right. I've had enough of this nonsense, listen carefully: as English isn't your first language I'll make this as simple as possible: 1) I didn't come here to start a flame war, but rather to point out a genuine deficiency in the Windows getpass, compared to the *nix version. 2) You didn't lie, and *I didn't accuse you of that*, but rather pointed out that all was not correct or complete in your assertion. *I* was right, as you carefully neglected to mention that you're using a native keyboard, with an NLS system that puts ? below ASCII 127 in your local codepage 3) getpass.getpass(), when called on *nix, allows me to input '?' and every other character under the sun. When called on Windows, *it does not*. This Means Complex Passwords With getpass() Aren't Portable. End Of Story. It Is Undocumented. This Is A Bug. 4) Yes the problem isn't that getch() isn't doing what it should, it is that getch() is the *wrong function to use* in order to gain parity with the *nix version. 5) Finally, you seem hell-bent on ignoring what I've written. I was wrong about getch() behaviour on python-dev, but That Isn't The Problem, which is why *I* didn't mention it in this initial bug-report. My assertion below that getch() won't get anything above ASCII 255 is *completely accurate*. It is the Wrong Function To Use. This Is A Bug In Getpass. 6) Finally, Finally, please read this and understand: As per the initial bug-report, the problem is that getpass on Windows is limited in ways that getpass on *nix isn't. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 12:01 Message: Logged In: YES user_id=1188172 First of all, don't accuse me of lying. If I wanted to lie professionally, I would have become politician, not programmer. I'm German, and using a German keyboard layout which does have the ?, so it can be perfectly input. Your problem is that you cannot input characters which don't directly create keycodes on the keyboard, but must be copied to the console in some way. In python-dev, you said that msvcrt.getch() would have to call _getch() a second time in the case that it returns 0x00 or 0xe0 the first time and/or return a Unicode string. First, the documentation for _getch() says that this is a special case for arrow and function keys (such as F1 or ). These keys don't have a representation in any character set, as they are control keys, so how would you represent them as Unicode? Second: In my console, pressing F7 yields the return values "\x00" and "A". When the 0x00/0xe0 read the first time is secretly swallowed, the user of msvcrt.getch() can't know whether the user pressed "A" or F7. That said, the behaviour of getch() is documented and correct. But how does that all help you with your original problem, which is that _getch() doesn't help you with Alt+XXXX sequences or console window Copy-Paste? In my understanding _getch() only works with characters directly input to the console. Sorry, but then this is not a Python problem but a Windows one. ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 11:18 Message: Logged In: YES user_id=567623 I think that, because I've read the source, and getpass.getpass() uses msvcrt.getch() on Windows, which doesn't support anything at all above ASCII 255. Also because I have a bug report pending against one of the projects that I maintain from a user that is experiencing a problem because of exactly this issue. See: https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935 Also, I call shenanigans on your claim of successfully inputting an umlaut-u into getpass.getpass(); this character can *theoretically* be input, as it's below ASCII 255, but in practice I can neither input it directly, nor COPY+PASTE it from the clipboard on my WinXP SP2 with Python 2.4.1 installed. Finally, regardless of whether "?" works or not, other characters that live solely in unicode, such as "?" most certainly do not (and never will) work (not even theoretically). Regards, D ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 10:46 Message: Logged In: YES user_id=1188172 What makes you think that? I tried it on Windows XP, in a cmd.exe session. I could enter, for example, an ? (umlauted u), which in the resulting string came out encoded as \x81, as is correct in the encoding used by the console window, namely cp850. I could then convert this to latin1 by using s.decode(sys.stdin.encoding).encode("latin-1"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 From noreply at sourceforge.net Thu Jul 7 12:42:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 03:42:55 -0700 Subject: [ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix Message-ID: Bugs item #1233785, was opened at 2005-07-07 09:36 Message generated for change (Comment added) made by esrever_otua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 Please note that this 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: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. ---------------------------------------------------------------------- >Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 22:42 Message: Logged In: YES user_id=567623 I am not an expert C coder (no surprise) however this simple code I wrote will accept a line of input (including the \r\n on the end) without echoing it back to the user: #include #define LINE_BUF 65536 char *getstr(){ /* * OK, basically, we get a handle to STDIN, take a copy of the * flags currently in force, set our own to prevent screen echo, * do a read of the console that returns on '\r\n' (included in * returned string), restore the original flags on STDIN, and * finally returns the input string. * * This is basically a re-implementation of getch(), but instead * of a single char, you get a whole string (with no screen echo). * * For docs on functions called, see: * http://msdn.microsoft.com/library/en-us/dllproc/base/console_functions.asp */ HANDLE hstdin; DWORD read_chars, mode; char in_chars[LINE_BUF]; hstdin = GetStdHandle(STD_INPUT_HANDLE); GetConsoleMode(hstdin, &mode); SetConsoleMode(hstdin, ENABLE_LINE_INPUT | ENABLE_PROCESSED_INPUT); ReadConsole(hstdin, in_chars, LINE_BUF, &read_chars, NULL); SetConsoleMode(hstdin, mode); return in_chars; } This code, when SWIG-ed to use with Python 2.4.1 works perfectly. The key is setting the flags on the console handle to remove the ENABLE_ECHO_INPUT flag. Also, if ENABLE_LINE_INPUT is removed, theoretically the ReadConsole() function should return after each typed character. On *nix you can use unicode_start and loadkeys to input unicode directly, including ALT+xxxx style input. Regards, D ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 22:29 Message: Logged In: YES user_id=1188172 Okay. This isn't menat to attempt a flamewar, but rather find out what can be done to help you (and, thank you very much for making it simple extra for me, I would have preferred the simple version even if I was a native speaker). You're right that this bug report is about getpass's portability, I had a bit lost track of this. Since you posted the link to your tracker in your previous comment, I somehow linked this to here. I have only two questions left. 1) Do you know another function in the MS API that allows reading a character from the console without displaying it? 2) How do you input your characters under the sun on Unix? Can you do this on a text console, too? ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 22:15 Message: Logged In: YES user_id=567623 Right. I've had enough of this nonsense, listen carefully: as English isn't your first language I'll make this as simple as possible: 1) I didn't come here to start a flame war, but rather to point out a genuine deficiency in the Windows getpass, compared to the *nix version. 2) You didn't lie, and *I didn't accuse you of that*, but rather pointed out that all was not correct or complete in your assertion. *I* was right, as you carefully neglected to mention that you're using a native keyboard, with an NLS system that puts ? below ASCII 127 in your local codepage 3) getpass.getpass(), when called on *nix, allows me to input '?' and every other character under the sun. When called on Windows, *it does not*. This Means Complex Passwords With getpass() Aren't Portable. End Of Story. It Is Undocumented. This Is A Bug. 4) Yes the problem isn't that getch() isn't doing what it should, it is that getch() is the *wrong function to use* in order to gain parity with the *nix version. 5) Finally, you seem hell-bent on ignoring what I've written. I was wrong about getch() behaviour on python-dev, but That Isn't The Problem, which is why *I* didn't mention it in this initial bug-report. My assertion below that getch() won't get anything above ASCII 255 is *completely accurate*. It is the Wrong Function To Use. This Is A Bug In Getpass. 6) Finally, Finally, please read this and understand: As per the initial bug-report, the problem is that getpass on Windows is limited in ways that getpass on *nix isn't. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 22:01 Message: Logged In: YES user_id=1188172 First of all, don't accuse me of lying. If I wanted to lie professionally, I would have become politician, not programmer. I'm German, and using a German keyboard layout which does have the ?, so it can be perfectly input. Your problem is that you cannot input characters which don't directly create keycodes on the keyboard, but must be copied to the console in some way. In python-dev, you said that msvcrt.getch() would have to call _getch() a second time in the case that it returns 0x00 or 0xe0 the first time and/or return a Unicode string. First, the documentation for _getch() says that this is a special case for arrow and function keys (such as F1 or ). These keys don't have a representation in any character set, as they are control keys, so how would you represent them as Unicode? Second: In my console, pressing F7 yields the return values "\x00" and "A". When the 0x00/0xe0 read the first time is secretly swallowed, the user of msvcrt.getch() can't know whether the user pressed "A" or F7. That said, the behaviour of getch() is documented and correct. But how does that all help you with your original problem, which is that _getch() doesn't help you with Alt+XXXX sequences or console window Copy-Paste? In my understanding _getch() only works with characters directly input to the console. Sorry, but then this is not a Python problem but a Windows one. ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 21:18 Message: Logged In: YES user_id=567623 I think that, because I've read the source, and getpass.getpass() uses msvcrt.getch() on Windows, which doesn't support anything at all above ASCII 255. Also because I have a bug report pending against one of the projects that I maintain from a user that is experiencing a problem because of exactly this issue. See: https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935 Also, I call shenanigans on your claim of successfully inputting an umlaut-u into getpass.getpass(); this character can *theoretically* be input, as it's below ASCII 255, but in practice I can neither input it directly, nor COPY+PASTE it from the clipboard on my WinXP SP2 with Python 2.4.1 installed. Finally, regardless of whether "?" works or not, other characters that live solely in unicode, such as "?" most certainly do not (and never will) work (not even theoretically). Regards, D ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 20:46 Message: Logged In: YES user_id=1188172 What makes you think that? I tried it on Windows XP, in a cmd.exe session. I could enter, for example, an ? (umlauted u), which in the resulting string came out encoded as \x81, as is correct in the encoding used by the console window, namely cp850. I could then convert this to latin1 by using s.decode(sys.stdin.encoding).encode("latin-1"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 From noreply at sourceforge.net Thu Jul 7 13:39:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 04:39:52 -0700 Subject: [ python-Bugs-1234123 ] datetime.strftime %s Message-ID: Bugs item #1234123, was opened at 2005-07-07 13:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234123&group_id=5470 Please note that this message 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: Peter Kleiweg (peterkleiweg) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.strftime %s Initial Comment: I don't know if this is a bug in datetime or in pytz, so I submitted this as a bug with pytz as well: https://sourceforge.net/tracker/index.php?func=detail&aid=1233776&group_id=79122&atid=555590 The first example does not give the result I expect. The second does. Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 >>> from datetime import datetime >>> from pytz import timezone >>> utc = timezone('UTC') >>> utc_dt = datetime(1970, 1, 1, 0, 0, 0, tzinfo=utc) >>> print utc_dt 1970-01-01 00:00:00+00:00 >>> print utc_dt.strftime('%c * %Z * %s') Thu Jan 1 00:00:00 1970 * UTC * -3600 Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 >>> import os >>> os.environ['TZ'] = 'UTC' >>> from datetime import datetime >>> from pytz import timezone >>> utc = timezone('UTC') >>> utc_dt = datetime(1970, 1, 1, 0, 0, 0, tzinfo=utc) >>> print utc_dt 1970-01-01 00:00:00+00:00 >>> print utc_dt.strftime('%c * %Z * %s') Thu Jan 1 00:00:00 1970 * UTC * 0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234123&group_id=5470 From noreply at sourceforge.net Thu Jul 7 20:01:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 11:01:05 -0700 Subject: [ python-Bugs-1234328 ] 'insufficient disk space' message wrong (msi on win xp pro) Message-ID: Bugs item #1234328, was opened at 2005-07-07 20: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=1234328&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) Assigned to: Nobody/Anonymous (nobody) Summary: 'insufficient disk space' message wrong (msi on win xp pro) Initial Comment: I'm trying to do a non-admin install of python 2.4.1 using the msi on win xp pro. Our environment is pretty customized; in an ordinary explorer window I see drives I, J but no C. "My Documents" refers to i:\ which is an alias for \\\username. I'm installing to i:\\python241 for my user only. The server has enough diskspace and my diskspace is not limited. When I try to install, bug #1232947 occurs; but when I try to do the same install with a usb-stick attached (which appears as volume "e:"), the installer complains that E has insufficient disk space. In fact, this was true: but I was not installing on E but on I. The disk usage button by the way shows enough diskspace on I: and does not list E: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234328&group_id=5470 From noreply at sourceforge.net Fri Jul 8 00:37:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 15:37:48 -0700 Subject: [ python-Bugs-1234473 ] configure: error: cannot compute sizeof (int), 77 Message-ID: Bugs item #1234473, was opened at 2005-07-07 16:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&group_id=5470 Please note that this 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: Tekhne (tekhne0) Assigned to: Nobody/Anonymous (nobody) Summary: configure: error: cannot compute sizeof (int), 77 Initial Comment: After running: shell# configure --prefix=/opt/python Various warnings were produced, and one fatal error preventing the build from progressing: checking size of int... configure: error: cannot compute sizeof (int), 77 The attachment contains the config.log file from the configure command. Build was done with Python 2.4.1 on Solaris 10 (sparc) with gcc 3.3.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&group_id=5470 From noreply at sourceforge.net Fri Jul 8 00:44:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 15:44:44 -0700 Subject: [ python-Bugs-1234473 ] configure: error: cannot compute sizeof (int), 77 Message-ID: Bugs item #1234473, was opened at 2005-07-07 16:37 Message generated for change (Comment added) made by tekhne0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&group_id=5470 Please note that this 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: Tekhne (tekhne0) Assigned to: Nobody/Anonymous (nobody) Summary: configure: error: cannot compute sizeof (int), 77 Initial Comment: After running: shell# configure --prefix=/opt/python Various warnings were produced, and one fatal error preventing the build from progressing: checking size of int... configure: error: cannot compute sizeof (int), 77 The attachment contains the config.log file from the configure command. Build was done with Python 2.4.1 on Solaris 10 (sparc) with gcc 3.3.2. ---------------------------------------------------------------------- >Comment By: Tekhne (tekhne0) Date: 2005-07-07 16:44 Message: Logged In: YES user_id=1309274 attachment didn't go through...trying again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&group_id=5470 From noreply at sourceforge.net Fri Jul 8 01:26:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 16:26:59 -0700 Subject: [ python-Bugs-900092 ] hotshot.stats.load Message-ID: Bugs item #900092, was opened at 2004-02-19 03:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 Please note that this 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: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: hotshot.stats.load Initial Comment: trying to do a hotshot.stats.load("myprofiling_file.prof") fails with assertionerror assert not self._stack python 2.3.2 on WinXP ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-07-07 19:26 Message: Logged In: YES user_id=12800 See 900092-patch.txt for a candidate patch against Python 2.4.1. Props to Justin Campbell for most of the heavily lifting (but you can blame me for any problems ;). This fix restore the tracing of a 'return' event for exceptions that cause a function to exit. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:54 Message: Logged In: YES user_id=86307 Well, the superficial fix doesn't work (sorry for posting too soon). It turns out that PyTrace_EXCEPTION is sent for any exception, not just one causing the function to exit. So I guess the best fix may be to have hotshot always install its profiler_callback to handle CALLS and RETURNS, and then optionally install the tracer_callback to handle only LINEs. Anyway, that works for the one test case I've been using (a runcall of a function which simply does "import pickle"). By the way, I'm testing with 2.4b1. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:32 Message: Logged In: YES user_id=86307 I ran into this today, so I decided to look into it. It looks to me like the problem only happens if you profile with lineevents enabled. In that case, hotshot uses the tracer_callback function (in _hotshot.c) to dispatch trace events. This function explicitly ignores exception returns (PyTrace_EXCEPTION), which can lead to an unbalanced stack of calls/returns when the log is loaded (if an profiled function exits with an exception). It seems on the surface that tracer_callback ought to handle exceptions the same way as normal returns. This would be consistent with what happens when profiler_callback is used, since PyEval_EvalFrame dispatches sends a Py_RETURN to c_profilefunc when exiting because of an exception. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 10:41 Message: Logged In: YES user_id=12800 Could this be related to 1019882? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 18:00 Message: Logged In: YES user_id=469548 Hmm, the file was too big, even though it was compressed. I've uploaded it to http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2 now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 17:58 Message: Logged In: YES user_id=469548 While the original report isn't very useful, I've ran into this problem multiple times as well. I can reproduce it using the attached profile file (compressed because of the large size) and the following console session: Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> stats = hotshot.stats.load('roundup.prof') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load assert not self._stack AssertionError >>> I'm not sure who's baby hotshot really is, so I'm leaving this unassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 From noreply at sourceforge.net Fri Jul 8 01:27:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jul 2005 16:27:37 -0700 Subject: [ python-Bugs-900092 ] hotshot.stats.load Message-ID: Bugs item #900092, was opened at 2004-02-19 03:05 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 Please note that this message 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: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: hotshot.stats.load Initial Comment: trying to do a hotshot.stats.load("myprofiling_file.prof") fails with assertionerror assert not self._stack python 2.3.2 on WinXP ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-07-07 19:26 Message: Logged In: YES user_id=12800 See 900092-patch.txt for a candidate patch against Python 2.4.1. Props to Justin Campbell for most of the heavily lifting (but you can blame me for any problems ;). This fix restore the tracing of a 'return' event for exceptions that cause a function to exit. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:54 Message: Logged In: YES user_id=86307 Well, the superficial fix doesn't work (sorry for posting too soon). It turns out that PyTrace_EXCEPTION is sent for any exception, not just one causing the function to exit. So I guess the best fix may be to have hotshot always install its profiler_callback to handle CALLS and RETURNS, and then optionally install the tracer_callback to handle only LINEs. Anyway, that works for the one test case I've been using (a runcall of a function which simply does "import pickle"). By the way, I'm testing with 2.4b1. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:32 Message: Logged In: YES user_id=86307 I ran into this today, so I decided to look into it. It looks to me like the problem only happens if you profile with lineevents enabled. In that case, hotshot uses the tracer_callback function (in _hotshot.c) to dispatch trace events. This function explicitly ignores exception returns (PyTrace_EXCEPTION), which can lead to an unbalanced stack of calls/returns when the log is loaded (if an profiled function exits with an exception). It seems on the surface that tracer_callback ought to handle exceptions the same way as normal returns. This would be consistent with what happens when profiler_callback is used, since PyEval_EvalFrame dispatches sends a Py_RETURN to c_profilefunc when exiting because of an exception. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 10:41 Message: Logged In: YES user_id=12800 Could this be related to 1019882? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 18:00 Message: Logged In: YES user_id=469548 Hmm, the file was too big, even though it was compressed. I've uploaded it to http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2 now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 17:58 Message: Logged In: YES user_id=469548 While the original report isn't very useful, I've ran into this problem multiple times as well. I can reproduce it using the attached profile file (compressed because of the large size) and the following console session: Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> stats = hotshot.stats.load('roundup.prof') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load assert not self._stack AssertionError >>> I'm not sure who's baby hotshot really is, so I'm leaving this unassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 From noreply at sourceforge.net Fri Jul 8 11:01:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 02:01:20 -0700 Subject: [ python-Bugs-1234674 ] filecmp.cmp's "shallow" option Message-ID: Bugs item #1234674, was opened at 2005-07-08 09: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=1234674&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Mendez (goatsofmendez) Assigned to: Nobody/Anonymous (nobody) Summary: filecmp.cmp's "shallow" option Initial Comment: The filecmp.cmp function has a shallow option (set as default) to only compare files based on stats rather than doing a bit by bit comparison of the file itself. The relevant bit of the code follows. s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False result = _cache.get((f1, f2)) if result and (s1, s2) == result[:2]: return result[2] outcome = _do_cmp(f1, f2) _cache[f1, f2] = s1, s2, outcome return outcome There's a check to see if the shallow mode is enabled and if that's the case and the stats match it returns true but the test for returning false is for only one of the stats attributes meaning that it's possible for a file not to match either test and the function to carry on to the full file check lower down. The check above to see if the stats match with stat.S_IFREG also looks wrong to me, but it could just be I don't understand what he's trying to do :) This code is the same in both 2.3 and 2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&group_id=5470 From noreply at sourceforge.net Fri Jul 8 16:17:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 07:17:16 -0700 Subject: [ python-Bugs-900092 ] hotshot.stats.load Message-ID: Bugs item #900092, was opened at 2004-02-19 03:05 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 Please note that this message 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: Simon Dahlbacka (sdahlbac) >Assigned to: Brett Cannon (bcannon) Summary: hotshot.stats.load Initial Comment: trying to do a hotshot.stats.load("myprofiling_file.prof") fails with assertionerror assert not self._stack python 2.3.2 on WinXP ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-07-07 19:26 Message: Logged In: YES user_id=12800 See 900092-patch.txt for a candidate patch against Python 2.4.1. Props to Justin Campbell for most of the heavily lifting (but you can blame me for any problems ;). This fix restore the tracing of a 'return' event for exceptions that cause a function to exit. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:54 Message: Logged In: YES user_id=86307 Well, the superficial fix doesn't work (sorry for posting too soon). It turns out that PyTrace_EXCEPTION is sent for any exception, not just one causing the function to exit. So I guess the best fix may be to have hotshot always install its profiler_callback to handle CALLS and RETURNS, and then optionally install the tracer_callback to handle only LINEs. Anyway, that works for the one test case I've been using (a runcall of a function which simply does "import pickle"). By the way, I'm testing with 2.4b1. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:32 Message: Logged In: YES user_id=86307 I ran into this today, so I decided to look into it. It looks to me like the problem only happens if you profile with lineevents enabled. In that case, hotshot uses the tracer_callback function (in _hotshot.c) to dispatch trace events. This function explicitly ignores exception returns (PyTrace_EXCEPTION), which can lead to an unbalanced stack of calls/returns when the log is loaded (if an profiled function exits with an exception). It seems on the surface that tracer_callback ought to handle exceptions the same way as normal returns. This would be consistent with what happens when profiler_callback is used, since PyEval_EvalFrame dispatches sends a Py_RETURN to c_profilefunc when exiting because of an exception. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 10:41 Message: Logged In: YES user_id=12800 Could this be related to 1019882? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 18:00 Message: Logged In: YES user_id=469548 Hmm, the file was too big, even though it was compressed. I've uploaded it to http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2 now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 17:58 Message: Logged In: YES user_id=469548 While the original report isn't very useful, I've ran into this problem multiple times as well. I can reproduce it using the attached profile file (compressed because of the large size) and the following console session: Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> stats = hotshot.stats.load('roundup.prof') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load assert not self._stack AssertionError >>> I'm not sure who's baby hotshot really is, so I'm leaving this unassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 From noreply at sourceforge.net Fri Jul 8 17:02:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 08:02:43 -0700 Subject: [ python-Bugs-900092 ] hotshot.stats.load Message-ID: Bugs item #900092, was opened at 2004-02-19 03:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 Please note that this message 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: Simon Dahlbacka (sdahlbac) Assigned to: Brett Cannon (bcannon) Summary: hotshot.stats.load Initial Comment: trying to do a hotshot.stats.load("myprofiling_file.prof") fails with assertionerror assert not self._stack python 2.3.2 on WinXP ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-07-08 11:02 Message: Logged In: YES user_id=12800 900092-patch-2.txt fixes the test suite for the extra return event. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-07-07 19:26 Message: Logged In: YES user_id=12800 See 900092-patch.txt for a candidate patch against Python 2.4.1. Props to Justin Campbell for most of the heavily lifting (but you can blame me for any problems ;). This fix restore the tracing of a 'return' event for exceptions that cause a function to exit. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:54 Message: Logged In: YES user_id=86307 Well, the superficial fix doesn't work (sorry for posting too soon). It turns out that PyTrace_EXCEPTION is sent for any exception, not just one causing the function to exit. So I guess the best fix may be to have hotshot always install its profiler_callback to handle CALLS and RETURNS, and then optionally install the tracer_callback to handle only LINEs. Anyway, that works for the one test case I've been using (a runcall of a function which simply does "import pickle"). By the way, I'm testing with 2.4b1. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-08 18:32 Message: Logged In: YES user_id=86307 I ran into this today, so I decided to look into it. It looks to me like the problem only happens if you profile with lineevents enabled. In that case, hotshot uses the tracer_callback function (in _hotshot.c) to dispatch trace events. This function explicitly ignores exception returns (PyTrace_EXCEPTION), which can lead to an unbalanced stack of calls/returns when the log is loaded (if an profiled function exits with an exception). It seems on the surface that tracer_callback ought to handle exceptions the same way as normal returns. This would be consistent with what happens when profiler_callback is used, since PyEval_EvalFrame dispatches sends a Py_RETURN to c_profilefunc when exiting because of an exception. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 10:41 Message: Logged In: YES user_id=12800 Could this be related to 1019882? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 18:00 Message: Logged In: YES user_id=469548 Hmm, the file was too big, even though it was compressed. I've uploaded it to http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2 now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 17:58 Message: Logged In: YES user_id=469548 While the original report isn't very useful, I've ran into this problem multiple times as well. I can reproduce it using the attached profile file (compressed because of the large size) and the following console session: Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> stats = hotshot.stats.load('roundup.prof') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load assert not self._stack AssertionError >>> I'm not sure who's baby hotshot really is, so I'm leaving this unassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 From noreply at sourceforge.net Fri Jul 8 17:52:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 08:52:37 -0700 Subject: [ python-Bugs-1234850 ] Admin privs required for Windows? Message-ID: Bugs item #1234850, was opened at 2005-07-08 11:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 From noreply at sourceforge.net Fri Jul 8 18:36:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 09:36:11 -0700 Subject: [ python-Bugs-1234850 ] Admin privs required for Windows? Message-ID: Bugs item #1234850, was opened at 2005-07-08 09:52 Message generated for change (Comment added) made by hairypalm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. ---------------------------------------------------------------------- Comment By: Alex (hairypalm) Date: 2005-07-08 10:36 Message: Logged In: YES user_id=1309592 I am the original "complainant". I cannot try python 2.4 install package because it requires MSVCR71.dll. I am "locked down" at work and cannot write files except to my own user area. I am also prevented from writing to some areas of the registry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 From noreply at sourceforge.net Fri Jul 8 19:11:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 10:11:22 -0700 Subject: [ python-Bugs-1234850 ] Admin privs required for Windows? Message-ID: Bugs item #1234850, was opened at 2005-07-08 11:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-08 13:11 Message: Logged In: YES user_id=31435 You should be able to try 2.4. The Python installer includes msvcr71.dll, and should install it into the Python directory (instead of into a system directory) is you do a "install just for me" (as opposed to "all users") install. ---------------------------------------------------------------------- Comment By: Alex (hairypalm) Date: 2005-07-08 12:36 Message: Logged In: YES user_id=1309592 I am the original "complainant". I cannot try python 2.4 install package because it requires MSVCR71.dll. I am "locked down" at work and cannot write files except to my own user area. I am also prevented from writing to some areas of the registry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 From noreply at sourceforge.net Fri Jul 8 20:48:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 11:48:07 -0700 Subject: [ python-Bugs-1234850 ] Admin privs required for Windows? Message-ID: Bugs item #1234850, was opened at 2005-07-08 17:52 Message generated for change (Comment added) made by pvrijlandt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. ---------------------------------------------------------------------- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-07-08 20:48 Message: Logged In: YES user_id=1307917 Did you see bug # 1232947? It provides documentation of another failing non-admin install. (2.4.1). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=31435 You should be able to try 2.4. The Python installer includes msvcr71.dll, and should install it into the Python directory (instead of into a system directory) is you do a "install just for me" (as opposed to "all users") install. ---------------------------------------------------------------------- Comment By: Alex (hairypalm) Date: 2005-07-08 18:36 Message: Logged In: YES user_id=1309592 I am the original "complainant". I cannot try python 2.4 install package because it requires MSVCR71.dll. I am "locked down" at work and cannot write files except to my own user area. I am also prevented from writing to some areas of the registry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 From noreply at sourceforge.net Fri Jul 8 20:53:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 11:53:49 -0700 Subject: [ python-Feature Requests-1214675 ] module warnings lacks a remove filter function Message-ID: Feature Requests item #1214675, was opened at 2005-06-04 03:37 Message generated for change (Comment added) made by cconnett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 Please note that this message 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: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: module warnings lacks a remove filter function Initial Comment: In the module warnings, there is no function for removing certain items from the list of warnings filters. The only options are to empty the list completely or to manipulate the warnings.filters list directly, both of which is unfortunate in my opinion. I attached a file with a removefilter() function. I don't know how safe it is to complete regular expressions, however, it works nicely for me. ---------------------------------------------------------------------- Comment By: Chris Connett (cconnett) Date: 2005-07-08 14:53 Message: Logged In: YES user_id=1140166 ISTM the most common use case for this would be to set up some filter, perform some operation, then remove the filter. In this case, the removal wouldn't be far from the insertion, so it might not be unreasonable to keep around a reference to the added filter and remove it by identity when it's no longer needed ... if such a reference were available that is! As it stands, one does not get back a reference to the filter tuple added by filterwarnings(), so the only options left are to immediately grab warnings.filters[0], or construct one's own filter tuple manually (yech!). Some way should be provided to work in this case at least. As an aside, with 2.5's proposed context managers, a filter context could be added to this module so that a filter could be added and removed around the operation with a 'with' block. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-27 00:22 Message: Logged In: YES user_id=80475 I'm concerned that removefilter() may not work well in the presence of multiple modules that use the warnings module. It may be difficult to make sure the one removed wasn't subsequently added another module. Also, the issue is compounded because the order of filter application is important. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-04 08:48 Message: Logged In: YES user_id=6656 Pfft, this isn't Java! I'm not sure it should be done with impunity, but as a documented interface it makes perfect sense to me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2005-06-04 06:35 Message: Logged In: YES user_id=442234 It's simpler of course. However, if it's relatively easy to avoid, a module user should not manipulate module data structures directly, I think. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 05:33 Message: Logged In: YES user_id=1188172 I don't know, but wouldn't it be simpler to just document the warnings.filters attribute so that people know how to manipulate the list of filters? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 From noreply at sourceforge.net Fri Jul 8 20:59:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 11:59:46 -0700 Subject: [ python-Bugs-1234850 ] Admin privs required for Windows? Message-ID: Bugs item #1234850, was opened at 2005-07-08 11:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-08 14:59 Message: Logged In: YES user_id=31435 Bug 1232947 is about installing Python itself. This one is about installing a 3rd-party package that happens to use Python (a pre-existing Python), using a Windows installer created by Python's distutils package. It's unlikely the bugs have anything in common. ---------------------------------------------------------------------- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-07-08 14:48 Message: Logged In: YES user_id=1307917 Did you see bug # 1232947? It provides documentation of another failing non-admin install. (2.4.1). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 13:11 Message: Logged In: YES user_id=31435 You should be able to try 2.4. The Python installer includes msvcr71.dll, and should install it into the Python directory (instead of into a system directory) is you do a "install just for me" (as opposed to "all users") install. ---------------------------------------------------------------------- Comment By: Alex (hairypalm) Date: 2005-07-08 12:36 Message: Logged In: YES user_id=1309592 I am the original "complainant". I cannot try python 2.4 install package because it requires MSVCR71.dll. I am "locked down" at work and cannot write files except to my own user area. I am also prevented from writing to some areas of the registry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 From noreply at sourceforge.net Fri Jul 8 22:36:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 13:36:37 -0700 Subject: [ python-Bugs-1234956 ] Tutorial Section 6.3 example wrong Message-ID: Bugs item #1234956, was opened at 2005-07-08 20:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234956&group_id=5470 Please note that this 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: Phoebus Chen (phoebusc) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial Section 6.3 example wrong Initial Comment: On page: http://www.python.org/doc/2.4.1/tut/node8.html Section 6.3 It has the example: Without arguments, dir() lists the names you have defined currently: >>> a = [1, 2, 3, 4, 5] >>> import fibo, sys >>> fib = fibo.fib >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', 'fib', 'fib2'] These results for dir() are not correct (for example a is not listed) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234956&group_id=5470 From noreply at sourceforge.net Fri Jul 8 22:50:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 13:50:34 -0700 Subject: [ python-Bugs-1234965 ] ConfigParser generating strings I can't compare Message-ID: Bugs item #1234965, was opened at 2005-07-08 20: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=1234965&group_id=5470 Please note that this message 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: Robert Guico (lpangelrob) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser generating strings I can't compare Initial Comment: This is better demonstrated than described: Assume the following "myconfig.cfg" in the current directory... [main] OPT=no The following occurs from the command line: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 >>> from ConfigParser import ConfigParser >>> p = ConfigParser() >>> p.read('myconfig.cfg') ['myconfig.cfg'] >>> configWord = p.get('main','OPT') >>> configWord 'no' >>> word = 'no' >>> word 'no' >>> configWord is word False >>> word2 = 'no' >>> word2 'no' >>> word2 is word True >>> len(word) 2 >>> len(configWord) 2 >>> type(configWord) >>> type(word) In other words, the config values ConfigParser generates look a lot like strings, have types like strings, and have the same lengths as strings, but can't be compared as strings. This smells like a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234965&group_id=5470 From noreply at sourceforge.net Fri Jul 8 22:57:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 13:57:21 -0700 Subject: [ python-Bugs-1234965 ] ConfigParser generating strings I can't compare Message-ID: Bugs item #1234965, was opened at 2005-07-08 16:50 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234965&group_id=5470 Please note that this message 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: Robert Guico (lpangelrob) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser generating strings I can't compare Initial Comment: This is better demonstrated than described: Assume the following "myconfig.cfg" in the current directory... [main] OPT=no The following occurs from the command line: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 >>> from ConfigParser import ConfigParser >>> p = ConfigParser() >>> p.read('myconfig.cfg') ['myconfig.cfg'] >>> configWord = p.get('main','OPT') >>> configWord 'no' >>> word = 'no' >>> word 'no' >>> configWord is word False >>> word2 = 'no' >>> word2 'no' >>> word2 is word True >>> len(word) 2 >>> len(configWord) 2 >>> type(configWord) >>> type(word) In other words, the config values ConfigParser generates look a lot like strings, have types like strings, and have the same lengths as strings, but can't be compared as strings. This smells like a bug. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-08 16:57 Message: Logged In: YES user_id=31435 You should never use "is" to compare strings for equality (unless you have deep knowledge of what you're doing, and your application code guarantees to use unique string objects). Use "==" instead. For more about when you can and can't rely on "is", please start a discussion on comp.lang.python (or use Google to find the many previous discussions). It's not "a bug", and won't change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234965&group_id=5470 From noreply at sourceforge.net Fri Jul 8 23:25:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 14:25:12 -0700 Subject: [ python-Bugs-1234979 ] Lock.acquire treats only 1 as True Message-ID: Bugs item #1234979, was opened at 2005-07-08 17: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=1234979&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Chris Perkins (cperkins) Assigned to: Nobody/Anonymous (nobody) Summary: Lock.acquire treats only 1 as True Initial Comment: Lock.acquire takes an argument indicating whether or not to block. On Windows, an argument of 1 (or True) is treated as True, and any other number is treated as False. The problem is in PyThread_acquire_lock, in thread_nt.h. Although I haven't tried it on any other platform, looking at a random sample (thread_pthread.h and thread_solaris.h), it looks to me like other platforms do it right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 From noreply at sourceforge.net Fri Jul 8 23:29:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 14:29:29 -0700 Subject: [ python-Bugs-1234956 ] Tutorial Section 6.3 example wrong Message-ID: Bugs item #1234956, was opened at 2005-07-08 22:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234956&group_id=5470 Please note that this 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: Out of Date Priority: 5 Submitted By: Phoebus Chen (phoebusc) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial Section 6.3 example wrong Initial Comment: On page: http://www.python.org/doc/2.4.1/tut/node8.html Section 6.3 It has the example: Without arguments, dir() lists the names you have defined currently: >>> a = [1, 2, 3, 4, 5] >>> import fibo, sys >>> fib = fibo.fib >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', 'fib', 'fib2'] These results for dir() are not correct (for example a is not listed) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 23:29 Message: Logged In: YES user_id=1188172 This has already been fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234956&group_id=5470 From noreply at sourceforge.net Fri Jul 8 23:37:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 14:37:02 -0700 Subject: [ python-Bugs-969757 ] function and method objects confounded in Tutorial Message-ID: Bugs item #969757, was opened at 2004-06-09 18:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969757&group_id=5470 Please note that this 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: Mark Jackson (mjackson) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: function and method objects confounded in Tutorial Initial Comment: In Section 9.3.2 (Class Objects) we find, right after the MyClass example code: "then MyClass.i and MyClass.f are valid attribute references, returning an integer and a method object, respectively." However, at the end of Section 9.3.3 (Instance Objects) we find, referring to the same example: "But x.f is not the same thing as MyClass.f - it is a method object, not a function object." There are references to MyClass.f as a function or function object in Section 9.3.4 as well. Although Python terminology doesn't seem to be completely consistent around this point (in the Python 2.1.3 interpreter MyClass.f describes itself as an "unbound method") iit seems clear that calling MyClass.f a method object in Section 9.3.2 is, in this context, an error. Should be changed to "function object." ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 23:37 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed as Doc/tut/tut.tex r1.275, r1.261.2.10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969757&group_id=5470 From noreply at sourceforge.net Fri Jul 8 23:46:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 14:46:21 -0700 Subject: [ python-Bugs-1234985 ] using some_re.sub() often imports sre.__doc__ Message-ID: Bugs item #1234985, was opened at 2005-07-09 00: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=1234985&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Gustavo Niemeyer (niemeyer) Summary: using some_re.sub() often imports sre.__doc__ Initial Comment: Why is __doc__ imported from the builtin sre module when a regular expression is substituted replacing a group? $ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def import_hook(name, globals={}, locals={}, fromlist=[]): ... print name, fromlist ... return original_import(name, globals, locals, fromlist) ... >>> import __builtin__ >>> original_import = __builtin__.__import__ >>> __builtin__.__import__ = import_hook >>> import re re None sre ('*',) sys None sre_compile None _sre None sys None sre_constants ('*',) sre_parse None sys None sre_constants ('*',) sre_parse None copy_reg None sre ('__all__',) >>> re1 = re.compile('foo...bar') sre_parse None >>> re1.sub('x', 'y') 'y' >>> re1.sub('x', 'fooXXXbar') 'x' >>> re2 = re.compile('foo(...)bar') sre_parse None >>> re2.sub('x', 'y') 'y' >>> re2.sub('\1', 'fooXXXbar') sre ['__doc__'] 'XXX' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234985&group_id=5470 From noreply at sourceforge.net Fri Jul 8 23:48:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 14:48:20 -0700 Subject: [ python-Bugs-1002398 ] os.path.sameopenfile documentation wrong. Message-ID: Bugs item #1002398, was opened at 2004-08-03 05:35 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002398&group_id=5470 Please note that this 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: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.sameopenfile documentation wrong. Initial Comment: At http://docs.python.org/lib/module-os.path.html it very clearly states this: sameopenfile(fp1, fp2) Return True if the file objects fp1 and fp2 refer to the same file. The two file objects may represent different file descriptors. Availability: Macintosh, Unix. However, on my OSX box, the source to posixpath.py clearly says otherwise: def sameopenfile(fp1, fp2): """Test whether two open file objects reference the same file""" s1 = os.fstat(fp1) s2 = os.fstat(fp2) return samestat(s1, s2) I.e., sameopenfile accepts two integer filenos, not two file objects. Running it gives this exception: File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/site-packages/supybot/plugins/Tail.py", line 77, in samefile return os.path.sameopenfile(fd1, fd2) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/posixpath.py", line 220, in sameopenfile s1 = os.fstat(fp1) TypeError: an integer is required Perhaps the (much more useful) documented behavior can be retained, and two if statements added to the definition of sameopenfile: if not isinstance(fp1, int): fp1 = fp1.fileno() if not isinstance(fp2, int): fp2 = fp2.fileno() ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 23:48 Message: Logged In: YES user_id=1188172 The question is, should we fix the docs or the implementation? Or add the suggested hybrid-solution (drawback: no other function that deals with files currently allows file objects and descriptors). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002398&group_id=5470 From noreply at sourceforge.net Fri Jul 8 23:52:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 14:52:05 -0700 Subject: [ python-Bugs-1234985 ] using some_re.sub() often imports sre.__doc__ Message-ID: Bugs item #1234985, was opened at 2005-07-09 00:46 Message generated for change (Comment added) made by stevea_zope You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234985&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Gustavo Niemeyer (niemeyer) Summary: using some_re.sub() often imports sre.__doc__ Initial Comment: Why is __doc__ imported from the builtin sre module when a regular expression is substituted replacing a group? $ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def import_hook(name, globals={}, locals={}, fromlist=[]): ... print name, fromlist ... return original_import(name, globals, locals, fromlist) ... >>> import __builtin__ >>> original_import = __builtin__.__import__ >>> __builtin__.__import__ = import_hook >>> import re re None sre ('*',) sys None sre_compile None _sre None sys None sre_constants ('*',) sre_parse None sys None sre_constants ('*',) sre_parse None copy_reg None sre ('__all__',) >>> re1 = re.compile('foo...bar') sre_parse None >>> re1.sub('x', 'y') 'y' >>> re1.sub('x', 'fooXXXbar') 'x' >>> re2 = re.compile('foo(...)bar') sre_parse None >>> re2.sub('x', 'y') 'y' >>> re2.sub('\1', 'fooXXXbar') sre ['__doc__'] 'XXX' ---------------------------------------------------------------------- >Comment By: Steve Alexander (stevea_zope) Date: 2005-07-09 00:52 Message: Logged In: YES user_id=492001 This is significant for programs that use an expensive import hook, and also use this kind of regex. I'm working around this by making my import hook return early for imports from sre. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234985&group_id=5470 From noreply at sourceforge.net Fri Jul 8 23:59:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 14:59:55 -0700 Subject: [ python-Bugs-1234979 ] Lock.acquire treats only 1 as True Message-ID: Bugs item #1234979, was opened at 2005-07-08 23:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Chris Perkins (cperkins) >Assigned to: Raymond Hettinger (rhettinger) Summary: Lock.acquire treats only 1 as True Initial Comment: Lock.acquire takes an argument indicating whether or not to block. On Windows, an argument of 1 (or True) is treated as True, and any other number is treated as False. The problem is in PyThread_acquire_lock, in thread_nt.h. Although I haven't tried it on any other platform, looking at a random sample (thread_pthread.h and thread_solaris.h), it looks to me like other platforms do it right. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 23:59 Message: Logged In: YES user_id=1188172 Attaching a patch fixing that. Of course, the change is slightly backwards-incompatible, so should we do that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 From noreply at sourceforge.net Sat Jul 9 00:10:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 15:10:13 -0700 Subject: [ python-Bugs-1234979 ] Lock.acquire treats only 1 as True Message-ID: Bugs item #1234979, was opened at 2005-07-08 17:25 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Chris Perkins (cperkins) Assigned to: Raymond Hettinger (rhettinger) Summary: Lock.acquire treats only 1 as True Initial Comment: Lock.acquire takes an argument indicating whether or not to block. On Windows, an argument of 1 (or True) is treated as True, and any other number is treated as False. The problem is in PyThread_acquire_lock, in thread_nt.h. Although I haven't tried it on any other platform, looking at a random sample (thread_pthread.h and thread_solaris.h), it looks to me like other platforms do it right. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-08 18:10 Message: Logged In: YES user_id=31435 birkenfeld, yes we should: lock.acquire(waitflag) has been documented for more than a decade as treating any non-zero value as true, so this is a clear bug in thread_nt.h -- if someone was, e.g., relying on lock.acquire(2) acting like lock.acquire(0) on Windows, tough luck for them. I'd even include this patch in a bugfix release, since the current meaning of lock.acquire(2) varies across platforms because of this bug, and that's a potentially serious problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 17:59 Message: Logged In: YES user_id=1188172 Attaching a patch fixing that. Of course, the change is slightly backwards-incompatible, so should we do that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 From noreply at sourceforge.net Sat Jul 9 00:26:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jul 2005 15:26:26 -0700 Subject: [ python-Bugs-1234979 ] Lock.acquire treats only 1 as True Message-ID: Bugs item #1234979, was opened at 2005-07-08 23:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 Please note that this 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: 5 Submitted By: Chris Perkins (cperkins) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Lock.acquire treats only 1 as True Initial Comment: Lock.acquire takes an argument indicating whether or not to block. On Windows, an argument of 1 (or True) is treated as True, and any other number is treated as False. The problem is in PyThread_acquire_lock, in thread_nt.h. Although I haven't tried it on any other platform, looking at a random sample (thread_pthread.h and thread_solaris.h), it looks to me like other platforms do it right. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 00:26 Message: Logged In: YES user_id=1188172 Okay. Committed as Python/thread_nt.h r2.23.10.1, r2.24. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-09 00:10 Message: Logged In: YES user_id=31435 birkenfeld, yes we should: lock.acquire(waitflag) has been documented for more than a decade as treating any non-zero value as true, so this is a clear bug in thread_nt.h -- if someone was, e.g., relying on lock.acquire(2) acting like lock.acquire(0) on Windows, tough luck for them. I'd even include this patch in a bugfix release, since the current meaning of lock.acquire(2) varies across platforms because of this bug, and that's a potentially serious problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 23:59 Message: Logged In: YES user_id=1188172 Attaching a patch fixing that. Of course, the change is slightly backwards-incompatible, so should we do that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 From noreply at sourceforge.net Sat Jul 9 16:43:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 07:43:08 -0700 Subject: [ python-Bugs-1234979 ] Lock.acquire treats only 1 as True Message-ID: Bugs item #1234979, was opened at 2005-07-08 17:25 Message generated for change (Comment added) made by cperkins You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 Please note that this 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: 5 Submitted By: Chris Perkins (cperkins) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Lock.acquire treats only 1 as True Initial Comment: Lock.acquire takes an argument indicating whether or not to block. On Windows, an argument of 1 (or True) is treated as True, and any other number is treated as False. The problem is in PyThread_acquire_lock, in thread_nt.h. Although I haven't tried it on any other platform, looking at a random sample (thread_pthread.h and thread_solaris.h), it looks to me like other platforms do it right. ---------------------------------------------------------------------- >Comment By: Chris Perkins (cperkins) Date: 2005-07-09 10:43 Message: Logged In: YES user_id=1142368 It looks like thread_wince.h suffers from the same problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 18:26 Message: Logged In: YES user_id=1188172 Okay. Committed as Python/thread_nt.h r2.23.10.1, r2.24. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 18:10 Message: Logged In: YES user_id=31435 birkenfeld, yes we should: lock.acquire(waitflag) has been documented for more than a decade as treating any non-zero value as true, so this is a clear bug in thread_nt.h -- if someone was, e.g., relying on lock.acquire(2) acting like lock.acquire(0) on Windows, tough luck for them. I'd even include this patch in a bugfix release, since the current meaning of lock.acquire(2) varies across platforms because of this bug, and that's a potentially serious problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 17:59 Message: Logged In: YES user_id=1188172 Attaching a patch fixing that. Of course, the change is slightly backwards-incompatible, so should we do that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 From noreply at sourceforge.net Sat Jul 9 17:27:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 08:27:22 -0700 Subject: [ python-Bugs-1234979 ] Lock.acquire treats only 1 as True Message-ID: Bugs item #1234979, was opened at 2005-07-08 23:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 Please note that this 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: 5 Submitted By: Chris Perkins (cperkins) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Lock.acquire treats only 1 as True Initial Comment: Lock.acquire takes an argument indicating whether or not to block. On Windows, an argument of 1 (or True) is treated as True, and any other number is treated as False. The problem is in PyThread_acquire_lock, in thread_nt.h. Although I haven't tried it on any other platform, looking at a random sample (thread_pthread.h and thread_solaris.h), it looks to me like other platforms do it right. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 17:27 Message: Logged In: YES user_id=1188172 I see. Fixed as Python/thread_wince.h r2.8, r2.7.30.1. ---------------------------------------------------------------------- Comment By: Chris Perkins (cperkins) Date: 2005-07-09 16:43 Message: Logged In: YES user_id=1142368 It looks like thread_wince.h suffers from the same problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 00:26 Message: Logged In: YES user_id=1188172 Okay. Committed as Python/thread_nt.h r2.23.10.1, r2.24. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-09 00:10 Message: Logged In: YES user_id=31435 birkenfeld, yes we should: lock.acquire(waitflag) has been documented for more than a decade as treating any non-zero value as true, so this is a clear bug in thread_nt.h -- if someone was, e.g., relying on lock.acquire(2) acting like lock.acquire(0) on Windows, tough luck for them. I'd even include this patch in a bugfix release, since the current meaning of lock.acquire(2) varies across platforms because of this bug, and that's a potentially serious problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-08 23:59 Message: Logged In: YES user_id=1188172 Attaching a patch fixing that. Of course, the change is slightly backwards-incompatible, so should we do that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470 From noreply at sourceforge.net Sat Jul 9 18:24:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 09:24:33 -0700 Subject: [ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent Message-ID: Bugs item #1235266, was opened at 2005-07-10 01: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=1235266&group_id=5470 Please note that this 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: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 From noreply at sourceforge.net Sat Jul 9 19:04:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jul 2005 10:04:31 -0700 Subject: [ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent Message-ID: Bugs item #1235266, was opened at 2005-07-09 18:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this 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: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 19:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 From noreply at sourceforge.net Sun Jul 10 10:00:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 01:00:23 -0700 Subject: [ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent Message-ID: Bugs item #1235266, was opened at 2005-07-09 18:24 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this 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: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-07-10 10:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 19:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 From noreply at sourceforge.net Sun Jul 10 14:18:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 05:18:39 -0700 Subject: [ python-Bugs-1235569 ] Inconsistent singleton constructor messages Message-ID: Bugs item #1235569, was opened at 2005-07-10 05: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=1235569&group_id=5470 Please note that this message 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: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 From noreply at sourceforge.net Sun Jul 10 15:28:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 06:28:24 -0700 Subject: [ python-Bugs-1235569 ] Inconsistent singleton constructor messages Message-ID: Bugs item #1235569, was opened at 2005-07-10 14:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 Please note that this message 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: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 15:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 From noreply at sourceforge.net Sun Jul 10 18:26:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 09:26:32 -0700 Subject: [ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent Message-ID: Bugs item #1235266, was opened at 2005-07-10 01:24 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this 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: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2005-07-11 01:26 Message: Logged In: YES user_id=671362 OK. I tested some GNU compression/decompression tools and comfirmed that they write debugging messages (displayed in verbose mode(-v)) to stderr. Now I'm leaning toward Reinhold's idea. > What about zipfile? > Should we print debug info to stderr there, too? Maybe yes. I'd be happy to volunteer for that patch. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-07-10 17:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 02:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 From noreply at sourceforge.net Sun Jul 10 18:55:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 09:55:32 -0700 Subject: [ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode Message-ID: Bugs item #1235646, was opened at 2005-07-10 18: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=1235646&group_id=5470 Please note that this 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: Sebastian Wangnick (wangnick) Assigned to: M.-A. Lemburg (lemburg) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 From noreply at sourceforge.net Sun Jul 10 23:19:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 14:19:13 -0700 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 09:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Please note that this message 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: Hallvard B Furuseth (hfuru) >Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-10 17:19 Message: Logged In: YES user_id=31435 Unassigned myself, since I don't plan to do anything else here. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-12-06 02:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no extra effort, avoid gotchas for newbies, no special cases, etc. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 14:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 03:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib/test/test_xrange.py; new revision: 1.2 Objects/rangeobject.c; new revision: 2.53 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 01:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 12:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 11:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 11:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 09:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Mon Jul 11 00:33:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 15:33:07 -0700 Subject: [ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c Message-ID: Bugs item #1185883, was opened at 2005-04-19 08:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470 Please note that this message 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: Kristj?n Valur (krisvale) Assigned to: Tim Peters (tim_one) Summary: PyObject_Realloc bug in obmalloc.c Initial Comment: obmalloc.c:835 If the previous block was not handled by obmalloc, and the realloc is for growing the block, this memcpy may cross a page boundary and cause a segmentation fault. This scenario can happen if a previous allocation failed to successfully allocate from the obmalloc pools, due to memory starvation or other reasons, but was successfully allocated by the c runtime. The solution is to query the actual size of the allocated block, and copy only so much memory. Most modern platforms provide size query functions complementing the malloc()/free() calls. on Windows, this is the _msize () function. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-10 18:33 Message: Logged In: YES user_id=31435 Repaired, in Misc/NEWS 1.1312 Objects/obmalloc.c 2.54 Should be backported to 2.4 maint. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-27 05:35 Message: Logged In: YES user_id=6656 Ping! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-19 11:34 Message: Logged In: YES user_id=31435 krisvale: Thank you for the very clear explanation. Even I understand this now . We won't use _msize here -- Python has to run under dozens of compilers and C libraries, and it's saner to give up on this "optimization" completely than to introduce a rat's nest of #ifdefs here. IOW, I expect the entire "if (nbytes <= SMALL_REQUEST_THRESHOLD)" block will go away, so that the platform realloc() gets called in every case obmalloc doesn't control the incoming block. BTW, note that there's no plan to do another release in the Python 2.3 line. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2005-04-19 11:22 Message: Logged In: YES user_id=1262199 The platform is windows 2000/2003 server, single threaded C runtime. I have only had the chance to do postmortem debugging on this but it would appear to be as you describe: The following page is not mapped in. Windows doesn?t use the setbrk() method of heap management and doesn?t automatically move the break. Rather they (the multiple heaps) requests pages as required. A malloc may have succeeded from a different page and copying to much from the old block close to the boundary caused an exception _at_ the page boundary. Fyi, old block was 68 bytes at 0x6d85efb8. This block ends at -effc. The new size requested was 108 bytes. Reading 108 bytes from this address caused an exception at address 0x6d85f000. As you know, reading past a malloc block results in undefined behaviour and sometimes this can mean a crash. I have patched python locally to use MIN(nbytes, _msize(p)) in stead and we are about to run the modified version on our server cluster. Nodes were dying quite regularly because of this. I'll let you know if this changes anyting in that aspect. Btw, I work for ccp games, and we are running the MMORPG eve online (www.eveonline.com) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-19 11:00 Message: Logged In: YES user_id=31435 mwh: Umm ... I don't understand what the claim is. For example, what HW does Python run on where memcpy segfaults just because the address range crosses a page boundary? If that's what's happening, sounds more like a bug in the platform memcpy. I can memcpy blocks spanning thousands of pages on my box -- and so can you . krisvale: which OS and which C are you using? It is true that this code may try to access a bit of memory that wasn't allocated. If that's at the end of the address space, then I could see a segfault happening. If it is, I doubt there's any portable way to fix it short of PyObject_Realloc never trying to take over small blocks it didn't control to begin with. Then the platform realloc() will segfault instead . ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2005-04-19 10:39 Message: Logged In: YES user_id=1262199 I can only say that I?ve been seeing this happeing with our software. Admittedly it's because we are eating up all memory due to other reasons, but we would like to deal with that with a MemoryError rather than a crash. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-19 10:30 Message: Logged In: YES user_id=6656 Tim, what do you think? This is a pretty unlikely scenario, it seems to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470 From noreply at sourceforge.net Mon Jul 11 01:07:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 16:07:02 -0700 Subject: [ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c Message-ID: Bugs item #1185883, was opened at 2005-04-19 07:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470 Please note that this message 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: Kristj?n Valur (krisvale) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PyObject_Realloc bug in obmalloc.c Initial Comment: obmalloc.c:835 If the previous block was not handled by obmalloc, and the realloc is for growing the block, this memcpy may cross a page boundary and cause a segmentation fault. This scenario can happen if a previous allocation failed to successfully allocate from the obmalloc pools, due to memory starvation or other reasons, but was successfully allocated by the c runtime. The solution is to query the actual size of the allocated block, and copy only so much memory. Most modern platforms provide size query functions complementing the malloc()/free() calls. on Windows, this is the _msize () function. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-10 18:07 Message: Logged In: YES user_id=80475 Reinhold, would you like to do the backport? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-10 17:33 Message: Logged In: YES user_id=31435 Repaired, in Misc/NEWS 1.1312 Objects/obmalloc.c 2.54 Should be backported to 2.4 maint. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-27 04:35 Message: Logged In: YES user_id=6656 Ping! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-19 10:34 Message: Logged In: YES user_id=31435 krisvale: Thank you for the very clear explanation. Even I understand this now . We won't use _msize here -- Python has to run under dozens of compilers and C libraries, and it's saner to give up on this "optimization" completely than to introduce a rat's nest of #ifdefs here. IOW, I expect the entire "if (nbytes <= SMALL_REQUEST_THRESHOLD)" block will go away, so that the platform realloc() gets called in every case obmalloc doesn't control the incoming block. BTW, note that there's no plan to do another release in the Python 2.3 line. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2005-04-19 10:22 Message: Logged In: YES user_id=1262199 The platform is windows 2000/2003 server, single threaded C runtime. I have only had the chance to do postmortem debugging on this but it would appear to be as you describe: The following page is not mapped in. Windows doesn?t use the setbrk() method of heap management and doesn?t automatically move the break. Rather they (the multiple heaps) requests pages as required. A malloc may have succeeded from a different page and copying to much from the old block close to the boundary caused an exception _at_ the page boundary. Fyi, old block was 68 bytes at 0x6d85efb8. This block ends at -effc. The new size requested was 108 bytes. Reading 108 bytes from this address caused an exception at address 0x6d85f000. As you know, reading past a malloc block results in undefined behaviour and sometimes this can mean a crash. I have patched python locally to use MIN(nbytes, _msize(p)) in stead and we are about to run the modified version on our server cluster. Nodes were dying quite regularly because of this. I'll let you know if this changes anyting in that aspect. Btw, I work for ccp games, and we are running the MMORPG eve online (www.eveonline.com) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-19 10:00 Message: Logged In: YES user_id=31435 mwh: Umm ... I don't understand what the claim is. For example, what HW does Python run on where memcpy segfaults just because the address range crosses a page boundary? If that's what's happening, sounds more like a bug in the platform memcpy. I can memcpy blocks spanning thousands of pages on my box -- and so can you . krisvale: which OS and which C are you using? It is true that this code may try to access a bit of memory that wasn't allocated. If that's at the end of the address space, then I could see a segfault happening. If it is, I doubt there's any portable way to fix it short of PyObject_Realloc never trying to take over small blocks it didn't control to begin with. Then the platform realloc() will segfault instead . ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2005-04-19 09:39 Message: Logged In: YES user_id=1262199 I can only say that I?ve been seeing this happeing with our software. Admittedly it's because we are eating up all memory due to other reasons, but we would like to deal with that with a MemoryError rather than a crash. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-19 09:30 Message: Logged In: YES user_id=6656 Tim, what do you think? This is a pretty unlikely scenario, it seems to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470 From noreply at sourceforge.net Mon Jul 11 01:11:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 16:11:59 -0700 Subject: [ python-Feature Requests-1003935 ] xrange overflows Message-ID: Feature Requests item #1003935, was opened at 2004-08-05 08:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&group_id=5470 Please note that this message 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: Hallvard B Furuseth (hfuru) >Assigned to: Raymond Hettinger (rhettinger) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-10 18:11 Message: Logged In: YES user_id=80475 Will look at it to see if there is something simple that can be done. These were design decisions -- xrange() and count() are supposed to be simple and fast -- with other tools being preferred if you are pushing beyond the limit of normal use cases. IOW, it is not worth crippling their performance just because someone has discovered cute ways of using sys.maxint. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-10 16:19 Message: Logged In: YES user_id=31435 Unassigned myself, since I don't plan to do anything else here. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-12-06 02:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no extra effort, avoid gotchas for newbies, no special cases, etc. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 13:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 02:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib/test/test_xrange.py; new revision: 1.2 Objects/rangeobject.c; new revision: 2.53 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 00:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 11:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 10:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 10:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 08:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&group_id=5470 From noreply at sourceforge.net Mon Jul 11 05:10:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 20:10:09 -0700 Subject: [ python-Bugs-1219840 ] Need locale arg to strftime() Message-ID: Bugs item #1219840, was opened at 2005-06-13 10:32 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 Please note that this message 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: Wilfredo Sanchez (wsanchez) Assigned to: Brett Cannon (bcannon) Summary: Need locale arg to strftime() Initial Comment: strftime()'s behavior is dependant on your current locale. Sometimes this is undesireable, such as when parsing HTTP dates (RFC 2068, 3.3.1), where on is expected to create and parse dates using English month and week names. A similar problem exists with the lower() string method. In either case locale magic isn't always desirable, and it would be useful to add a locale argument to specify which locale to use. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:10 Message: Logged In: YES user_id=357491 Since no one can seem to refute my logic I am closing this as invalid. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-06-14 19:14 Message: Logged In: YES user_id=357491 There is an issue with this idea. strftime() is just a wrapper around the ISO C library function. We have no direct control over the locale handling. This means that the locale used by strftime() is dictated by the locale that the ISO C libraries think you have. Best thing to do is to temporarily change the locale to what you need, use strftime(), and then set the locale back. PEP 342 would be nice for this. =) At best this is what strftime() would have to do behind the scenes for you. And the extra overhead is not totally desirable. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-14 01:59 Message: Logged In: YES user_id=80475 Brett, do you want to take this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219840&group_id=5470 From noreply at sourceforge.net Mon Jul 11 05:31:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 20:31:29 -0700 Subject: [ python-Bugs-1190012 ] ``from sys import stdin, `` doesn't raise a SyntaxError Message-ID: Bugs item #1190012, was opened at 2005-04-25 23:11 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190012&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: ``from sys import stdin,`` doesn't raise a SyntaxError Initial Comment: Python 2.4 raises a SyntaxError: "trailing comma not allowed without surrounding parentheses". Detected by test_compile. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:31 Message: Logged In: YES user_id=357491 Patch #1194895 was accepted and checked in; closing as fixed. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-05-04 16:14 Message: Logged In: YES user_id=699438 Patch 1194895 fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190012&group_id=5470 From noreply at sourceforge.net Mon Jul 11 05:37:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 20:37:43 -0700 Subject: [ python-Bugs-1190011 ] [AST] distinct code objects not created Message-ID: Bugs item #1190011, was opened at 2005-04-25 23:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&group_id=5470 Please note that this 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: Closed >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] distinct code objects not created Initial Comment: >> def f(): return ((lambda x=1: x), (lambda x=2: x)) >> f1, f2 = f() >> id(f1.func_code) != id(f2.func_code) The above does not hold true. It should according to test_compile (reported in HEAD as bug #1048870). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:37 Message: Logged In: YES user_id=357491 Looks fine to me. Checked in as rev. 1.1.2.3 . test_compile now passes! ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 05:11 Message: Logged In: YES user_id=1038590 The same fix mwh used for HEAD appears to work for the AST branch, too (it's just in a different source file). Patch attached, and kicking in Brett's direction for review. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:02 Message: Logged In: YES user_id=1038590 For the code above, Python 2.4.1 actually generates a single code object (that is, the comparison returns False). Looking closer at 1048870, this is expected, as the two lambdas are created on the same line. I'll look into this on the AST branch - I suspect the culprit may be our problems with getting the line numbering right. (FWIW, I worked out the UnboundLocal problem, and followed it up in the relevant bug, 1186353) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 01:26 Message: Logged In: YES user_id=1038590 This seems to be the least of lambda's problems. A number of regression tests currently fail with UnboundLocalErrors, after an argument of the form "lambda (x, y): x" is passed to a function for invocation. Assigning to myself, since I'm about to take a look at the current misbehaviour of lambdas (they must be simpler than genexps, right?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190011&group_id=5470 From noreply at sourceforge.net Mon Jul 11 05:44:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 20:44:28 -0700 Subject: [ python-Bugs-1186353 ] [AST] automatic unpacking of arguments broken Message-ID: Bugs item #1186353, was opened at 2005-04-19 16:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] automatic unpacking of arguments broken Initial Comment: The code ``(lambda (x, y): x)((3, 5))`` fails because the passed-in tuple is not unpacked into the arguments. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:44 Message: Logged In: YES user_id=357491 Applied in rev. 1.1.2.109 . Closed as accepted. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 03:34 Message: Logged In: YES user_id=1038590 After looking in all the wrong places, it turned out to be something simple in the compiler. I factored out the relevant code from the function compilation, so that lambda compilation can use it too. Assigning to Brett for review. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 02:41 Message: Logged In: YES user_id=1038590 Investigating lambda behaviour, as per comment on 1190011 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&group_id=5470 From noreply at sourceforge.net Mon Jul 11 05:45:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 20:45:18 -0700 Subject: [ python-Bugs-1186353 ] [AST] automatic unpacking of arguments broken Message-ID: Bugs item #1186353, was opened at 2005-04-19 16:37 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&group_id=5470 Please note that this 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: Closed Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] automatic unpacking of arguments broken Initial Comment: The code ``(lambda (x, y): x)((3, 5))`` fails because the passed-in tuple is not unpacked into the arguments. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:44 Message: Logged In: YES user_id=357491 Applied in rev. 1.1.2.109 . Closed as accepted. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 03:34 Message: Logged In: YES user_id=1038590 After looking in all the wrong places, it turned out to be something simple in the compiler. I factored out the relevant code from the function compilation, so that lambda compilation can use it too. Assigning to Brett for review. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 02:41 Message: Logged In: YES user_id=1038590 Investigating lambda behaviour, as per comment on 1190011 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186353&group_id=5470 From noreply at sourceforge.net Mon Jul 11 05:53:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 20:53:22 -0700 Subject: [ python-Bugs-1186195 ] [AST] genexps get scoping wrong Message-ID: Bugs item #1186195, was opened at 2005-04-19 12:02 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&group_id=5470 Please note that this 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: Closed >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: [AST] genexps get scoping wrong Initial Comment: test_genexps is failing because it is unable to find a global defined in a genexp that is returned. Here is the problem simplified: def f(n): return (i for i in xrange(n)) list(f(10)) Leads to ``SystemError: no locals when loading 'xrange'``. Comparing Python 2.4 bytecode: 1 0 LOAD_CONST 1 ( at 0x3931e0, file "", line 1>) 3 MAKE_FUNCTION 0 6 LOAD_GLOBAL 0 (xrange) 9 LOAD_FAST 0 (n) 12 CALL_FUNCTION 1 15 GET_ITER 16 CALL_FUNCTION 1 19 RETURN_VALUE 20 LOAD_CONST 0 (None) 23 RETURN_VALUE to AST bytecode: 1 0 LOAD_CLOSURE 0 (n) 3 BUILD_TUPLE 1 6 LOAD_CONST 1 ( at 0x5212e8, file "", line 1>) 9 MAKE_CLOSURE 0 12 LOAD_NAME 0 (xrange) 15 LOAD_DEREF 0 (n) 18 CALL_FUNCTION 1 21 GET_ITER 22 CALL_FUNCTION 1 25 RETURN_VALUE 26 LOAD_CONST 0 (None) 29 RETURN_VALUE makes it obvious something is off (no peepholer; turned it off in my build of 2.4). Looks like extraneous work is being done in making a closure. Seems like it will still work, though. Plus the usage of LOAD_NAME is wrong in the AST; LOAD_NAME gets an object from the local namespace based on its name instead of offset. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 20:53 Message: Logged In: YES user_id=357491 rev. 2.10.8.34 has the patch. Thanks, Nick. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 00:49 Message: Logged In: YES user_id=1038590 Scratch that comment about applying a similar methodology to the compiler stage - the need to correctly structure the generate bytecode makes things a lot uglier, so the simple trick I used to get the symbol table scoping right doesn't apply (the outer loops need to do things before *and after* the inner loops in the compiler stage). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 00:33 Message: Logged In: YES user_id=1038590 Tag, you're it :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 00:32 Message: Logged In: YES user_id=1038590 Patch attached that means test_genexps mostly passes for me. The two which still fail are actually problems with assignment statements (the AST branch does not yet intercept attempts to assign to genexps and produce a nice error message). I'm also much happier with the implementation technique I used this time around - something similar should work for the compiler implementation, hopefully permitting it to be simplified (I'm going to look at that now, and will post a separate patch if it works out). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-20 23:13 Message: Logged In: YES user_id=357491 OK, so basically what I figured out earlier today. I noticed that both genexps in 2.4 and the AST branch generated the same bytecode, so the only difference was how it was handling passing in arguments to the generator for its initial creation. I figured there was some jiggering in the compiler to note that the scoping in the genexp should not affect how variables were handled for its arguments. And as you said, the AST branch just doesn't take this into consideration as it should. I will see if I get to it, but I doubt I will (leaving town Friday for the weekend). I think this has justified fleshing out Python/compile.txt with a more thorough discussion of how the symbol table is generated. If you have any specific points you think should go in there, Nick (or anyone for that matter), please email them to me. Even explaining how the whole thing works would be a help. =) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-04-20 15:13 Message: Logged In: YES user_id=1038590 The compiler stage does some fancy footwork so that the outermost iterable is evaluated immediately, and passed as an argument to the genexp block. The symbol table generation needs similar footwork, but it doesn't have it. That is, the symbol table for the outermost iterable is being created in the genexp scope, instead of in the containing function's scope, but the actual execution is happening in the function scope. Hilarity ensues. . . My original testing didn't pick this up because I was using (1, 2, 3) as the outermost iterable - no name lookups in the outermost iterable to be affected! If you haven't figured out a fix for this part of the problem before Sunday, I should be able to get to it then. The location of the enter_scope and exit_scope in the symbol table pass for genexps needs adjusting so that the outermost iterable is NOT part of the new scope. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-19 17:30 Message: Logged In: YES user_id=357491 OK, figured out why the closure thing is happening. 'n' is being detected as a free variable. This leads to PyCode_GetNumFree() to return a non-0 value. In compiler_make_closure() this automatically triggers the LOAD_CLOSURE/.../MAKE_CLOSURE chunk of bytecode instead of LOAD_CONST/MAKE_FUNCTION. So, how to make 'n' be detected as a local instead a free variable ... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-19 17:09 Message: Logged In: YES user_id=357491 Some playing with gdb has turned up some clues. So LOAD_NAME is emitted by compiler_nameop(). How this partially works is that it gets the scope for an argument and then based on that emits the proper load, store, or delete. So why is xrange() coming out at the NAME scope? Well, turns out it is not being found in a particular scope by PyST_GetScope() and is thus returning 0 by default. This means that NAME becomes the scope for xrange(). So it looks like the symtable creation is screwing up and not making xrange() a global like it should. This might be a side-effect of the while closure thing above. Not sure, though. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-04-19 12:03 Message: Logged In: YES user_id=357491 Initially assigned to Nick since he did the genexp patch and in hopes he might know what is going on off the top of his head. Otherwise assign to me. I have a sneaking suspicion that the symtable code overall is slightly busted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186195&group_id=5470 From noreply at sourceforge.net Mon Jul 11 06:13:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 21:13:43 -0700 Subject: [ python-Bugs-1191458 ] [AST] Failing tests Message-ID: Bugs item #1191458, was opened at 2005-04-27 20:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 Please note that this 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: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 01:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 From noreply at sourceforge.net Mon Jul 11 06:15:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 21:15:00 -0700 Subject: [ python-Bugs-1191458 ] [AST] Failing tests Message-ID: Bugs item #1191458, was opened at 2005-04-27 20:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 Please note that this 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: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 01:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 From noreply at sourceforge.net Mon Jul 11 08:03:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 23:03:22 -0700 Subject: [ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c Message-ID: Bugs item #1185883, was opened at 2005-04-19 14:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470 Please note that this message 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: Kristj?n Valur (krisvale) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: PyObject_Realloc bug in obmalloc.c Initial Comment: obmalloc.c:835 If the previous block was not handled by obmalloc, and the realloc is for growing the block, this memcpy may cross a page boundary and cause a segmentation fault. This scenario can happen if a previous allocation failed to successfully allocate from the obmalloc pools, due to memory starvation or other reasons, but was successfully allocated by the c runtime. The solution is to query the actual size of the allocated block, and copy only so much memory. Most modern platforms provide size query functions complementing the malloc()/free() calls. on Windows, this is the _msize () function. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 08:03 Message: Logged In: YES user_id=1188172 Done. Misc/NEWS r1.1193.2.61, Objects/obmalloc.c r2.53.4.1. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 01:07 Message: Logged In: YES user_id=80475 Reinhold, would you like to do the backport? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-11 00:33 Message: Logged In: YES user_id=31435 Repaired, in Misc/NEWS 1.1312 Objects/obmalloc.c 2.54 Should be backported to 2.4 maint. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-27 11:35 Message: Logged In: YES user_id=6656 Ping! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-19 17:34 Message: Logged In: YES user_id=31435 krisvale: Thank you for the very clear explanation. Even I understand this now . We won't use _msize here -- Python has to run under dozens of compilers and C libraries, and it's saner to give up on this "optimization" completely than to introduce a rat's nest of #ifdefs here. IOW, I expect the entire "if (nbytes <= SMALL_REQUEST_THRESHOLD)" block will go away, so that the platform realloc() gets called in every case obmalloc doesn't control the incoming block. BTW, note that there's no plan to do another release in the Python 2.3 line. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2005-04-19 17:22 Message: Logged In: YES user_id=1262199 The platform is windows 2000/2003 server, single threaded C runtime. I have only had the chance to do postmortem debugging on this but it would appear to be as you describe: The following page is not mapped in. Windows doesn?t use the setbrk() method of heap management and doesn?t automatically move the break. Rather they (the multiple heaps) requests pages as required. A malloc may have succeeded from a different page and copying to much from the old block close to the boundary caused an exception _at_ the page boundary. Fyi, old block was 68 bytes at 0x6d85efb8. This block ends at -effc. The new size requested was 108 bytes. Reading 108 bytes from this address caused an exception at address 0x6d85f000. As you know, reading past a malloc block results in undefined behaviour and sometimes this can mean a crash. I have patched python locally to use MIN(nbytes, _msize(p)) in stead and we are about to run the modified version on our server cluster. Nodes were dying quite regularly because of this. I'll let you know if this changes anyting in that aspect. Btw, I work for ccp games, and we are running the MMORPG eve online (www.eveonline.com) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-19 17:00 Message: Logged In: YES user_id=31435 mwh: Umm ... I don't understand what the claim is. For example, what HW does Python run on where memcpy segfaults just because the address range crosses a page boundary? If that's what's happening, sounds more like a bug in the platform memcpy. I can memcpy blocks spanning thousands of pages on my box -- and so can you . krisvale: which OS and which C are you using? It is true that this code may try to access a bit of memory that wasn't allocated. If that's at the end of the address space, then I could see a segfault happening. If it is, I doubt there's any portable way to fix it short of PyObject_Realloc never trying to take over small blocks it didn't control to begin with. Then the platform realloc() will segfault instead . ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2005-04-19 16:39 Message: Logged In: YES user_id=1262199 I can only say that I?ve been seeing this happeing with our software. Admittedly it's because we are eating up all memory due to other reasons, but we would like to deal with that with a MemoryError rather than a crash. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-19 16:30 Message: Logged In: YES user_id=6656 Tim, what do you think? This is a pretty unlikely scenario, it seems to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&group_id=5470 From noreply at sourceforge.net Mon Jul 11 08:19:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jul 2005 23:19:19 -0700 Subject: [ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent Message-ID: Bugs item #1235266, was opened at 2005-07-09 18:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this 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: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 08:19 Message: Logged In: YES user_id=1188172 Attaching patches for both tarfile and zipfile. For tarfile, the docs are changed to stderr, for zipfile, both docs and implementation are changed to stderr. Since I don't assume that someone actually uses the debug info in some automated way, I think we can correct this in 2.5. Raymond, please review. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-07-10 18:26 Message: Logged In: YES user_id=671362 OK. I tested some GNU compression/decompression tools and comfirmed that they write debugging messages (displayed in verbose mode(-v)) to stderr. Now I'm leaning toward Reinhold's idea. > What about zipfile? > Should we print debug info to stderr there, too? Maybe yes. I'd be happy to volunteer for that patch. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-07-10 10:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 19:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 From noreply at sourceforge.net Mon Jul 11 12:16:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 03:16:12 -0700 Subject: [ python-Feature Requests-1003935 ] xrange overflows Message-ID: Feature Requests item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Comment added) made by hfuru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&group_id=5470 Please note that this message 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: Hallvard B Furuseth (hfuru) Assigned to: Raymond Hettinger (rhettinger) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Hallvard B Furuseth (hfuru) Date: 2005-07-11 12:16 Message: Logged In: YES user_id=726647 What is "cute" about using maxint as an xrange() limit, and why would it impact its performance to return its 2nd parameter as endvalue +/- 1 (an int) instead of trying to return endvalue + step (which can be long)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 01:11 Message: Logged In: YES user_id=80475 Will look at it to see if there is something simple that can be done. These were design decisions -- xrange() and count() are supposed to be simple and fast -- with other tools being preferred if you are pushing beyond the limit of normal use cases. IOW, it is not worth crippling their performance just because someone has discovered cute ways of using sys.maxint. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-10 23:19 Message: Logged In: YES user_id=31435 Unassigned myself, since I don't plan to do anything else here. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-12-06 08:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no extra effort, avoid gotchas for newbies, no special cases, etc. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 20:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 09:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib/test/test_xrange.py; new revision: 1.2 Objects/rangeobject.c; new revision: 2.53 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 07:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 18:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 17:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 17:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 15:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&group_id=5470 From noreply at sourceforge.net Mon Jul 11 16:12:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 07:12:42 -0700 Subject: [ python-Bugs-1236090 ] crashes in bgen wrappers Message-ID: Bugs item #1236090, was opened at 2005-07-11 15: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=1236090&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 8 Submitted By: Michael Hudson (mwh) Assigned to: Jack Jansen (jackjansen) Summary: crashes in bgen wrappers Initial Comment: There's something peculiar in the land of bgen-ed wrappers: $ ./python.exe Python 2.5a0 (#1, Jul 11 2005, 13:21:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Carbon.File [45313 refs] >>> Carbon.File.FSSpec(os.curdir).as_pathname() Segmentation fault ("make test" also crashes). This is on 10.3.9. My first investigations with gdb didn't reveal anything that made much sense, so it *might* be a compiler bug. At any rate, it didn't do this a few weeks ago... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&group_id=5470 From noreply at sourceforge.net Mon Jul 11 18:55:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 09:55:02 -0700 Subject: [ python-Bugs-1234850 ] Admin privs required for Windows? Message-ID: Bugs item #1234850, was opened at 2005-07-08 17:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 18:55 Message: Logged In: YES user_id=21627 The message comes from PC\bdist_wininst\install.c:OpenLogFile, when attempting to write to Software\Microsoft\CurrentVersion\Uninstall. Whether this goes to HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE apparently depends on whether Python was installed per-user or per-machine. In the 2.4.1 version, in CheckRootKey, there is a HasLocalMachinePrivs function. Mark Hammond added this in install.c 1.6 in response to #555812 and #555810, so I'm declaring this bug fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 20:59 Message: Logged In: YES user_id=31435 Bug 1232947 is about installing Python itself. This one is about installing a 3rd-party package that happens to use Python (a pre-existing Python), using a Windows installer created by Python's distutils package. It's unlikely the bugs have anything in common. ---------------------------------------------------------------------- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-07-08 20:48 Message: Logged In: YES user_id=1307917 Did you see bug # 1232947? It provides documentation of another failing non-admin install. (2.4.1). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=31435 You should be able to try 2.4. The Python installer includes msvcr71.dll, and should install it into the Python directory (instead of into a system directory) is you do a "install just for me" (as opposed to "all users") install. ---------------------------------------------------------------------- Comment By: Alex (hairypalm) Date: 2005-07-08 18:36 Message: Logged In: YES user_id=1309592 I am the original "complainant". I cannot try python 2.4 install package because it requires MSVCR71.dll. I am "locked down" at work and cannot write files except to my own user area. I am also prevented from writing to some areas of the registry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 From noreply at sourceforge.net Mon Jul 11 20:30:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 11:30:51 -0700 Subject: [ python-Bugs-1235569 ] Inconsistent singleton constructor messages Message-ID: Bugs item #1235569, was opened at 2005-07-10 05:18 Message generated for change (Comment added) made by ppergame You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 Please note that this message 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: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances ---------------------------------------------------------------------- >Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 11:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 06:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 From noreply at sourceforge.net Mon Jul 11 21:06:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 12:06:12 -0700 Subject: [ python-Bugs-893549 ] skipitem() in getargs.c missing some types Message-ID: Bugs item #893549, was opened at 2004-02-09 18:30 Message generated for change (Comment added) made by subik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 Please note that this message 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: Kirill A Kryloff (hacocuk) Assigned to: Nobody/Anonymous (nobody) Summary: skipitem() in getargs.c missing some types Initial Comment: python 2.2.3 looks like skipitem in getargs.c is missing some types 'k' for example ---------------------------------------------------------------------- Comment By: Petr Vaněk (subik) Date: 2005-07-11 21:06 Message: Logged In: YES user_id=784012 this bug is still presented in later versions 2.3, 2.4. We have real problem with it (see. http://bugs.scribus.net/view.php?id=2018). Broken PyArg_ParseTupleAndKeywords in skipitem() (getargs.c) causes "impossible" exception by missing case conditions. I would like to please developers for fixing (or we will be forced to provide a patch (which will force us to know Python guts (etc.))). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 14:10 Message: Logged In: YES user_id=1188172 The missing types are u, u#, es, es#, et, et#, k, K, I, U, t#, w, w# and maybe (...) I don't know whether this is of any significance though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 From noreply at sourceforge.net Mon Jul 11 21:08:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 12:08:29 -0700 Subject: [ python-Bugs-893549 ] skipitem() in getargs.c missing some types Message-ID: Bugs item #893549, was opened at 2004-02-10 01:30 Message generated for change (Comment added) made by ringerc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 Please note that this message 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: Kirill A Kryloff (hacocuk) Assigned to: Nobody/Anonymous (nobody) Summary: skipitem() in getargs.c missing some types Initial Comment: python 2.2.3 looks like skipitem in getargs.c is missing some types 'k' for example ---------------------------------------------------------------------- Comment By: Craig Ringer (ringerc) Date: 2005-07-12 03:08 Message: Logged In: YES user_id=639504 It matters all right. Just wasted a bunch of time tracking this down into the Python sources and confirming it was a Python bug. It's really nasty for 'es'. This will cause bizarre errors for PyArg_ParseTupleAndKeywords(...) calls using the unsupported format strings after the | optional argument barrier. The errors will always contain the string: impossible The error will, of course, only turn up if the user omits one or more of the arguments with unsupported formats. ---------------------------------------------------------------------- Comment By: Petr Vaněk (subik) Date: 2005-07-12 03:06 Message: Logged In: YES user_id=784012 this bug is still presented in later versions 2.3, 2.4. We have real problem with it (see. http://bugs.scribus.net/view.php?id=2018). Broken PyArg_ParseTupleAndKeywords in skipitem() (getargs.c) causes "impossible" exception by missing case conditions. I would like to please developers for fixing (or we will be forced to provide a patch (which will force us to know Python guts (etc.))). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:10 Message: Logged In: YES user_id=1188172 The missing types are u, u#, es, es#, et, et#, k, K, I, U, t#, w, w# and maybe (...) I don't know whether this is of any significance though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 From noreply at sourceforge.net Mon Jul 11 21:11:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 12:11:36 -0700 Subject: [ python-Bugs-893549 ] skipitem() in getargs.c missing some types Message-ID: Bugs item #893549, was opened at 2004-02-09 18:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 Please note that this message 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: Kirill A Kryloff (hacocuk) Assigned to: Nobody/Anonymous (nobody) Summary: skipitem() in getargs.c missing some types Initial Comment: python 2.2.3 looks like skipitem in getargs.c is missing some types 'k' for example ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 21:11 Message: Logged In: YES user_id=1188172 I submitted a patch (#1212928) which fixes that. ---------------------------------------------------------------------- Comment By: Craig Ringer (ringerc) Date: 2005-07-11 21:08 Message: Logged In: YES user_id=639504 It matters all right. Just wasted a bunch of time tracking this down into the Python sources and confirming it was a Python bug. It's really nasty for 'es'. This will cause bizarre errors for PyArg_ParseTupleAndKeywords(...) calls using the unsupported format strings after the | optional argument barrier. The errors will always contain the string: impossible The error will, of course, only turn up if the user omits one or more of the arguments with unsupported formats. ---------------------------------------------------------------------- Comment By: Petr Vaněk (subik) Date: 2005-07-11 21:06 Message: Logged In: YES user_id=784012 this bug is still presented in later versions 2.3, 2.4. We have real problem with it (see. http://bugs.scribus.net/view.php?id=2018). Broken PyArg_ParseTupleAndKeywords in skipitem() (getargs.c) causes "impossible" exception by missing case conditions. I would like to please developers for fixing (or we will be forced to provide a patch (which will force us to know Python guts (etc.))). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 14:10 Message: Logged In: YES user_id=1188172 The missing types are u, u#, es, es#, et, et#, k, K, I, U, t#, w, w# and maybe (...) I don't know whether this is of any significance though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 From noreply at sourceforge.net Mon Jul 11 22:17:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 13:17:35 -0700 Subject: [ python-Bugs-1235569 ] Inconsistent singleton constructor messages Message-ID: Bugs item #1235569, was opened at 2005-07-10 08:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 Please note that this message 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: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-11 16:17 Message: Logged In: YES user_id=31435 ppergame, could you please be explicit about what your complaint is here? I don't know what's bothering you either. For example, spell out the text for error messages you think would be OK. Your example: "fanction takes too mny arguements lol" seems meaningless here, since it appears to suggest you dislike spelling errors. That's fine, but there are no spelling errors in the messages you're complaining about. ---------------------------------------------------------------------- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 14:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 09:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 From noreply at sourceforge.net Mon Jul 11 22:22:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 13:22:22 -0700 Subject: [ python-Bugs-1235569 ] Inconsistent singleton constructor messages Message-ID: Bugs item #1235569, was opened at 2005-07-10 05:18 Message generated for change (Comment added) made by ppergame You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 Please note that this message 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: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances ---------------------------------------------------------------------- >Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 13:22 Message: Logged In: YES user_id=595126 Either the first error message should be changed to "TypeError: cannot create 'none' instances" or the second one should be "TypeError: cannot create 'EllipsisType' instances". I apologize for being unclear. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-11 13:17 Message: Logged In: YES user_id=31435 ppergame, could you please be explicit about what your complaint is here? I don't know what's bothering you either. For example, spell out the text for error messages you think would be OK. Your example: "fanction takes too mny arguements lol" seems meaningless here, since it appears to suggest you dislike spelling errors. That's fine, but there are no spelling errors in the messages you're complaining about. ---------------------------------------------------------------------- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 11:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 06:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 From noreply at sourceforge.net Mon Jul 11 22:43:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 13:43:09 -0700 Subject: [ python-Bugs-1235569 ] Inconsistent singleton constructor messages Message-ID: Bugs item #1235569, was opened at 2005-07-10 08:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 Please note that this message 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: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-11 16:43 Message: Logged In: YES user_id=31435 Ah! Well, we shouldn't do that -- the messages currently give the correct names for the types: >>> type(None) >>> type(Ellipsis) The names types are exported under by types.py are pretty much arbitrary, but shouldn't be changed either because doing so would create backward compatibility headaches. ---------------------------------------------------------------------- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 16:22 Message: Logged In: YES user_id=595126 Either the first error message should be changed to "TypeError: cannot create 'none' instances" or the second one should be "TypeError: cannot create 'EllipsisType' instances". I apologize for being unclear. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-11 16:17 Message: Logged In: YES user_id=31435 ppergame, could you please be explicit about what your complaint is here? I don't know what's bothering you either. For example, spell out the text for error messages you think would be OK. Your example: "fanction takes too mny arguements lol" seems meaningless here, since it appears to suggest you dislike spelling errors. That's fine, but there are no spelling errors in the messages you're complaining about. ---------------------------------------------------------------------- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 14:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 09:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 From noreply at sourceforge.net Tue Jul 12 00:24:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 15:24:40 -0700 Subject: [ python-Feature Requests-1003935 ] xrange overflows Message-ID: Feature Requests item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&group_id=5470 Please note that this message 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: Hallvard B Furuseth (hfuru) Assigned to: Raymond Hettinger (rhettinger) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-12 00:24 Message: Logged In: YES user_id=21627 Using xrange for an infinite loop qualifies as "cute" = "obviously straining for effect". The most natural way of an infinite loop is "while True". There are certainly other ways to express an infinite loop (like reading from /dev/zero, or writing an unbounded recursion), but arguing that xrange is "much faster" is obviously straining for effect: If the loop is infinite, how can it be much faster? And why does it matter if it is? (in my measurements, it is 30% faster, counting the time for a given number of iterations). ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2005-07-11 12:16 Message: Logged In: YES user_id=726647 What is "cute" about using maxint as an xrange() limit, and why would it impact its performance to return its 2nd parameter as endvalue +/- 1 (an int) instead of trying to return endvalue + step (which can be long)? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 01:11 Message: Logged In: YES user_id=80475 Will look at it to see if there is something simple that can be done. These were design decisions -- xrange() and count() are supposed to be simple and fast -- with other tools being preferred if you are pushing beyond the limit of normal use cases. IOW, it is not worth crippling their performance just because someone has discovered cute ways of using sys.maxint. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-10 23:19 Message: Logged In: YES user_id=31435 Unassigned myself, since I don't plan to do anything else here. ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-12-06 08:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no extra effort, avoid gotchas for newbies, no special cases, etc. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 20:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 09:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib/test/test_xrange.py; new revision: 1.2 Objects/rangeobject.c; new revision: 2.53 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 07:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 18:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 17:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 17:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 15:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&group_id=5470 From noreply at sourceforge.net Tue Jul 12 02:56:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 17:56:56 -0700 Subject: [ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix Message-ID: Bugs item #1233785, was opened at 2005-07-07 09:36 Message generated for change (Comment added) made by esrever_otua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 Please note that this 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: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. ---------------------------------------------------------------------- >Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-12 12:56 Message: Logged In: YES user_id=567623 Following on from earlier code; the code below implements a complete C module for Python that provides a 'getpass' implementation for windows that behaves similarly to existing getpass (accepts a prompt, returns a string without newlines). I'm not a fantastic C coder, so this is really just to provide ideas. /* * This file is part of 'win32console' * Copyright 2005 Darryl A. Dixon */ #include #include #include "Python.h" #define LINE_BUF 1024 * sizeof(TCHAR) #define CHAR_BUF 6 * sizeof(TCHAR) /* Module globals */ static PyObject *getpass_error = NULL; static PyObject *getpass(self, args) PyObject *self, *args; { char *prompt = "Password: "; char *newline = "\r\n"; if (PyArg_ParseTuple(args, "|s", &prompt)){ HANDLE hstdin, hstdout; DWORD read_chars, mode, written_chars; char inchars[LINE_BUF]; hstdout = GetStdHandle(STD_OUTPUT_HANDLE); WriteConsole(hstdout, prompt, strlen(prompt), &written_chars, NULL); hstdin = GetStdHandle(STD_INPUT_HANDLE); GetConsoleMode(hstdin, &mode); SetConsoleMode(hstdin, ENABLE_LINE_INPUT | ENABLE_PROCESSED_INPUT); /* Hmm, is allowing threads to run while we're playing with the flags on * STDIN such a good idea? ...Who knows... */ Py_BEGIN_ALLOW_THREADS ReadConsole(hstdin, inchars, LINE_BUF, &read_chars, NULL); Py_END_ALLOW_THREADS SetConsoleMode(hstdin, mode); WriteConsole(hstdout, newline, strlen(newline), &written_chars, NULL); /* -2 to strip the \015\012 from the end -------------v */ return PyString_FromStringAndSize(inchars, read_chars-2); }else{ return NULL; } } static PyObject *getch(self, args) PyObject *self, *args; { if (PyArg_ParseTuple(args, "")){ HANDLE hstdin; DWORD read_chars, mode; char inchars[CHAR_BUF]; hstdin = GetStdHandle(STD_INPUT_HANDLE); GetConsoleMode(hstdin, &mode); SetConsoleMode(hstdin, ENABLE_PROCESSED_INPUT); Py_BEGIN_ALLOW_THREADS ReadConsole(hstdin, inchars, CHAR_BUF, &read_chars, NULL); Py_END_ALLOW_THREADS SetConsoleMode(hstdin, mode); /* this should generally always be 1 ----------v */ return PyString_FromStringAndSize(inchars, read_chars); }else{ return NULL; } } static PyMethodDef methods[] = { {"getpass", getpass, METH_VARARGS}, {"getch", getch, METH_VARARGS}, {NULL, NULL}, }; void init_win32console(){ PyObject *mod, *dict; mod = Py_InitModule("_win32console", methods); dict = PyModule_GetDict(mod); #if PYTHON_API_VERSION >= 1007 getpass_error = PyErr_NewException("getpass.error", NULL, NULL); #else getpass_error = Py_BuildValue("s", "getpass.error"); #endif PyDict_SetItemString(dict, "error", getpass_error); } ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 22:42 Message: Logged In: YES user_id=567623 I am not an expert C coder (no surprise) however this simple code I wrote will accept a line of input (including the \r\n on the end) without echoing it back to the user: #include #define LINE_BUF 65536 char *getstr(){ /* * OK, basically, we get a handle to STDIN, take a copy of the * flags currently in force, set our own to prevent screen echo, * do a read of the console that returns on '\r\n' (included in * returned string), restore the original flags on STDIN, and * finally returns the input string. * * This is basically a re-implementation of getch(), but instead * of a single char, you get a whole string (with no screen echo). * * For docs on functions called, see: * http://msdn.microsoft.com/library/en-us/dllproc/base/console_functions.asp */ HANDLE hstdin; DWORD read_chars, mode; char in_chars[LINE_BUF]; hstdin = GetStdHandle(STD_INPUT_HANDLE); GetConsoleMode(hstdin, &mode); SetConsoleMode(hstdin, ENABLE_LINE_INPUT | ENABLE_PROCESSED_INPUT); ReadConsole(hstdin, in_chars, LINE_BUF, &read_chars, NULL); SetConsoleMode(hstdin, mode); return in_chars; } This code, when SWIG-ed to use with Python 2.4.1 works perfectly. The key is setting the flags on the console handle to remove the ENABLE_ECHO_INPUT flag. Also, if ENABLE_LINE_INPUT is removed, theoretically the ReadConsole() function should return after each typed character. On *nix you can use unicode_start and loadkeys to input unicode directly, including ALT+xxxx style input. Regards, D ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 22:29 Message: Logged In: YES user_id=1188172 Okay. This isn't menat to attempt a flamewar, but rather find out what can be done to help you (and, thank you very much for making it simple extra for me, I would have preferred the simple version even if I was a native speaker). You're right that this bug report is about getpass's portability, I had a bit lost track of this. Since you posted the link to your tracker in your previous comment, I somehow linked this to here. I have only two questions left. 1) Do you know another function in the MS API that allows reading a character from the console without displaying it? 2) How do you input your characters under the sun on Unix? Can you do this on a text console, too? ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 22:15 Message: Logged In: YES user_id=567623 Right. I've had enough of this nonsense, listen carefully: as English isn't your first language I'll make this as simple as possible: 1) I didn't come here to start a flame war, but rather to point out a genuine deficiency in the Windows getpass, compared to the *nix version. 2) You didn't lie, and *I didn't accuse you of that*, but rather pointed out that all was not correct or complete in your assertion. *I* was right, as you carefully neglected to mention that you're using a native keyboard, with an NLS system that puts ? below ASCII 127 in your local codepage 3) getpass.getpass(), when called on *nix, allows me to input '?' and every other character under the sun. When called on Windows, *it does not*. This Means Complex Passwords With getpass() Aren't Portable. End Of Story. It Is Undocumented. This Is A Bug. 4) Yes the problem isn't that getch() isn't doing what it should, it is that getch() is the *wrong function to use* in order to gain parity with the *nix version. 5) Finally, you seem hell-bent on ignoring what I've written. I was wrong about getch() behaviour on python-dev, but That Isn't The Problem, which is why *I* didn't mention it in this initial bug-report. My assertion below that getch() won't get anything above ASCII 255 is *completely accurate*. It is the Wrong Function To Use. This Is A Bug In Getpass. 6) Finally, Finally, please read this and understand: As per the initial bug-report, the problem is that getpass on Windows is limited in ways that getpass on *nix isn't. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 22:01 Message: Logged In: YES user_id=1188172 First of all, don't accuse me of lying. If I wanted to lie professionally, I would have become politician, not programmer. I'm German, and using a German keyboard layout which does have the ?, so it can be perfectly input. Your problem is that you cannot input characters which don't directly create keycodes on the keyboard, but must be copied to the console in some way. In python-dev, you said that msvcrt.getch() would have to call _getch() a second time in the case that it returns 0x00 or 0xe0 the first time and/or return a Unicode string. First, the documentation for _getch() says that this is a special case for arrow and function keys (such as F1 or ). These keys don't have a representation in any character set, as they are control keys, so how would you represent them as Unicode? Second: In my console, pressing F7 yields the return values "\x00" and "A". When the 0x00/0xe0 read the first time is secretly swallowed, the user of msvcrt.getch() can't know whether the user pressed "A" or F7. That said, the behaviour of getch() is documented and correct. But how does that all help you with your original problem, which is that _getch() doesn't help you with Alt+XXXX sequences or console window Copy-Paste? In my understanding _getch() only works with characters directly input to the console. Sorry, but then this is not a Python problem but a Windows one. ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 21:18 Message: Logged In: YES user_id=567623 I think that, because I've read the source, and getpass.getpass() uses msvcrt.getch() on Windows, which doesn't support anything at all above ASCII 255. Also because I have a bug report pending against one of the projects that I maintain from a user that is experiencing a problem because of exactly this issue. See: https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935 Also, I call shenanigans on your claim of successfully inputting an umlaut-u into getpass.getpass(); this character can *theoretically* be input, as it's below ASCII 255, but in practice I can neither input it directly, nor COPY+PASTE it from the clipboard on my WinXP SP2 with Python 2.4.1 installed. Finally, regardless of whether "?" works or not, other characters that live solely in unicode, such as "?" most certainly do not (and never will) work (not even theoretically). Regards, D ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 20:46 Message: Logged In: YES user_id=1188172 What makes you think that? I tried it on Windows XP, in a cmd.exe session. I could enter, for example, an ? (umlauted u), which in the resulting string came out encoded as \x81, as is correct in the encoding used by the console window, namely cp850. I could then convert this to latin1 by using s.decode(sys.stdin.encoding).encode("latin-1"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470 From noreply at sourceforge.net Tue Jul 12 05:00:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 20:00:02 -0700 Subject: [ python-Bugs-1235569 ] Inconsistent singleton constructor messages Message-ID: Bugs item #1235569, was opened at 2005-07-10 07:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 Please note that this message 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: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-11 15:43 Message: Logged In: YES user_id=31435 Ah! Well, we shouldn't do that -- the messages currently give the correct names for the types: >>> type(None) >>> type(Ellipsis) The names types are exported under by types.py are pretty much arbitrary, but shouldn't be changed either because doing so would create backward compatibility headaches. ---------------------------------------------------------------------- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 15:22 Message: Logged In: YES user_id=595126 Either the first error message should be changed to "TypeError: cannot create 'none' instances" or the second one should be "TypeError: cannot create 'EllipsisType' instances". I apologize for being unclear. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-11 15:17 Message: Logged In: YES user_id=31435 ppergame, could you please be explicit about what your complaint is here? I don't know what's bothering you either. For example, spell out the text for error messages you think would be OK. Your example: "fanction takes too mny arguements lol" seems meaningless here, since it appears to suggest you dislike spelling errors. That's fine, but there are no spelling errors in the messages you're complaining about. ---------------------------------------------------------------------- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 13:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 08:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 From noreply at sourceforge.net Tue Jul 12 05:06:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 20:06:03 -0700 Subject: [ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent Message-ID: Bugs item #1235266, was opened at 2005-07-09 11:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this 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: George Yoshida (quiver) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 22:06 Message: Logged In: YES user_id=80475 Just change the docs to match the actual behavior. Let's leave the implementation alone. There is no great need to have tarfile's implementation match zipfile. Someday, all of the modules will generate messages via the logging module and you'll trivially be able to mask them or redirect them in a consistent manner. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 01:19 Message: Logged In: YES user_id=1188172 Attaching patches for both tarfile and zipfile. For tarfile, the docs are changed to stderr, for zipfile, both docs and implementation are changed to stderr. Since I don't assume that someone actually uses the debug info in some automated way, I think we can correct this in 2.5. Raymond, please review. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-07-10 11:26 Message: Logged In: YES user_id=671362 OK. I tested some GNU compression/decompression tools and comfirmed that they write debugging messages (displayed in verbose mode(-v)) to stderr. Now I'm leaning toward Reinhold's idea. > What about zipfile? > Should we print debug info to stderr there, too? Maybe yes. I'd be happy to volunteer for that patch. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-07-10 03:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 12:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 From noreply at sourceforge.net Tue Jul 12 05:08:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jul 2005 20:08:24 -0700 Subject: [ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod Message-ID: Bugs item #1229429, was opened at 2005-06-28 21:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 Please note that this message 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: Gary (gdray-1) >Assigned to: Michael Hudson (mwh) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 22:08 Message: Logged In: YES user_id=80475 Assigning to the god of leak fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 From noreply at sourceforge.net Tue Jul 12 09:29:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 00:29:07 -0700 Subject: [ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent Message-ID: Bugs item #1235266, was opened at 2005-07-09 18:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this 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: George Yoshida (quiver) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 09:29 Message: Logged In: YES user_id=1188172 Okay. Checked in Doc/lib/libtarfile.tex r1.10, r1.7.2.1. And when will be some day? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 05:06 Message: Logged In: YES user_id=80475 Just change the docs to match the actual behavior. Let's leave the implementation alone. There is no great need to have tarfile's implementation match zipfile. Someday, all of the modules will generate messages via the logging module and you'll trivially be able to mask them or redirect them in a consistent manner. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 08:19 Message: Logged In: YES user_id=1188172 Attaching patches for both tarfile and zipfile. For tarfile, the docs are changed to stderr, for zipfile, both docs and implementation are changed to stderr. Since I don't assume that someone actually uses the debug info in some automated way, I think we can correct this in 2.5. Raymond, please review. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-07-10 18:26 Message: Logged In: YES user_id=671362 OK. I tested some GNU compression/decompression tools and comfirmed that they write debugging messages (displayed in verbose mode(-v)) to stderr. Now I'm leaning toward Reinhold's idea. > What about zipfile? > Should we print debug info to stderr there, too? Maybe yes. I'd be happy to volunteer for that patch. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-07-10 10:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 19:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 From noreply at sourceforge.net Tue Jul 12 12:23:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 03:23:01 -0700 Subject: [ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod Message-ID: Bugs item #1229429, was opened at 2005-06-29 03:18 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 Please note that this message 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: Gary (gdray-1) Assigned to: Michael Hudson (mwh) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-12 11:23 Message: Logged In: YES user_id=6656 Heh, it's a fair cop. Fixed in: Objects/abstract.c revision 2.137 Lib/test/test_enumerate.py revision 1.15 Misc/NEWS revision 1.1313 Raymond, while I have your attention, is the __reversed__ protocol tested anywhere? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 04:08 Message: Logged In: YES user_id=80475 Assigning to the god of leak fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 From noreply at sourceforge.net Tue Jul 12 12:31:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 03:31:42 -0700 Subject: [ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod Message-ID: Bugs item #1229429, was opened at 2005-06-28 21:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 Please note that this message 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: Gary (gdray-1) Assigned to: Michael Hudson (mwh) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 05:31 Message: Logged In: YES user_id=80475 It's not an official, documented protocol. It is an implementation detail (choosen as a way to decouple individual types from the general purpose reversed() code). It is tested via the types than implement __reversed__ (such as collections.deque). BTW, all the general testing for reversed is cleverly hidden in test_enumerate. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-12 05:23 Message: Logged In: YES user_id=6656 Heh, it's a fair cop. Fixed in: Objects/abstract.c revision 2.137 Lib/test/test_enumerate.py revision 1.15 Misc/NEWS revision 1.1313 Raymond, while I have your attention, is the __reversed__ protocol tested anywhere? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 22:08 Message: Logged In: YES user_id=80475 Assigning to the god of leak fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 From noreply at sourceforge.net Tue Jul 12 12:47:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 03:47:13 -0700 Subject: [ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod Message-ID: Bugs item #1229429, was opened at 2005-06-29 03:18 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary (gdray-1) Assigned to: Michael Hudson (mwh) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 11:31 Message: Logged In: YES user_id=80475 It's not an official, documented protocol. It is an implementation detail (choosen as a way to decouple individual types from the general purpose reversed() code). It is tested via the types than implement __reversed__ (such as collections.deque). BTW, all the general testing for reversed is cleverly hidden in test_enumerate. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-12 11:23 Message: Logged In: YES user_id=6656 Heh, it's a fair cop. Fixed in: Objects/abstract.c revision 2.137 Lib/test/test_enumerate.py revision 1.15 Misc/NEWS revision 1.1313 Raymond, while I have your attention, is the __reversed__ protocol tested anywhere? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 04:08 Message: Logged In: YES user_id=80475 Assigning to the god of leak fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 From noreply at sourceforge.net Tue Jul 12 12:59:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 03:59:08 -0700 Subject: [ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding" Message-ID: Bugs item #1232768, was opened at 2005-07-05 16:11 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 Please note that this 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: Matt Smart (mcsmart) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in online docs under "5.3 Pure Embedding" Initial Comment: I'm looking at the "5.3 Pure Embedding" page: http://python.org/doc/2.4.1/ext/pure-embedding.html 1. pFunc = PyDict_GetItemString(pDict, argv[2]); - /* pFun: Borrowed reference */ + /* pFunc: Borrowed reference */ 2. The code snippet in the section starting with "After initializing the interpreter," does not follow the code in the example. It uses PyObject_GetAttrString() instead of PyObject_GetItemString(), which creates a new reference instead of borrowing one, and therefore needs a Py_XDEREF(pFunc) call that is also not in the initial example. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 12:59 Message: Logged In: YES user_id=174455 These seem to have been fixed already in CVS (although I can't find a duplicate report). Suggest closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 From noreply at sourceforge.net Tue Jul 12 13:35:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 04:35:12 -0700 Subject: [ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding" Message-ID: Bugs item #1232768, was opened at 2005-07-05 16:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 Please note that this 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: Matt Smart (mcsmart) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in online docs under "5.3 Pure Embedding" Initial Comment: I'm looking at the "5.3 Pure Embedding" page: http://python.org/doc/2.4.1/ext/pure-embedding.html 1. pFunc = PyDict_GetItemString(pDict, argv[2]); - /* pFun: Borrowed reference */ + /* pFunc: Borrowed reference */ 2. The code snippet in the section starting with "After initializing the interpreter," does not follow the code in the example. It uses PyObject_GetAttrString() instead of PyObject_GetItemString(), which creates a new reference instead of borrowing one, and therefore needs a Py_XDEREF(pFunc) call that is also not in the initial example. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 13:35 Message: Logged In: YES user_id=1188172 Only the first part has been fixed. The second is beyond my decision and must be considered by someone other. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 12:59 Message: Logged In: YES user_id=174455 These seem to have been fixed already in CVS (although I can't find a duplicate report). Suggest closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 From noreply at sourceforge.net Tue Jul 12 14:57:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 05:57:46 -0700 Subject: [ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding" Message-ID: Bugs item #1232768, was opened at 2005-07-05 16:11 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 Please note that this 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: Matt Smart (mcsmart) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in online docs under "5.3 Pure Embedding" Initial Comment: I'm looking at the "5.3 Pure Embedding" page: http://python.org/doc/2.4.1/ext/pure-embedding.html 1. pFunc = PyDict_GetItemString(pDict, argv[2]); - /* pFun: Borrowed reference */ + /* pFunc: Borrowed reference */ 2. The code snippet in the section starting with "After initializing the interpreter," does not follow the code in the example. It uses PyObject_GetAttrString() instead of PyObject_GetItemString(), which creates a new reference instead of borrowing one, and therefore needs a Py_XDEREF(pFunc) call that is also not in the initial example. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 14:57 Message: Logged In: YES user_id=174455 Reinhold, I must confess I am confused. I'm trying to unravel what goes in in CVS with all the branches. It seems this was corrected in rev. 1.5 of embedding.tex (from 2002!?). Looking at cvs (HEAD) I also see: python/dist/src/Doc/ext/embedding.tex (line ~180): \begin{verbatim} pFunc = PyObject_GetAttrString(pModule, argv[2]); /* pFunc is a new reference */ if (pFunc && PyCallable_Check(pFunc)) { ... } Py_XDECREF(pFunc); \end{verbatim} This seems to fix the problem? Also looking at http://python.org/doc/2.4.1/ext/pure-embedding.html *today* I don't see 'Borrowed reference' and but 'a new reference' and including a PyXDEREF. Am I totally missing the point of the bug-report or is the time-machine flying again? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 13:35 Message: Logged In: YES user_id=1188172 Only the first part has been fixed. The second is beyond my decision and must be considered by someone other. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 12:59 Message: Logged In: YES user_id=174455 These seem to have been fixed already in CVS (although I can't find a duplicate report). Suggest closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 From noreply at sourceforge.net Tue Jul 12 15:10:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 06:10:29 -0700 Subject: [ python-Bugs-1233799 ] tkFileDialog.askopen... fails when dir="" Message-ID: Bugs item #1233799, was opened at 2005-07-06 17:08 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.askopen... fails when dir="" Initial Comment: The following simple code fails on MacOS X 10.3 running the built- in python 2.3 and Aqua Tcl/Tk 8.4.9: import Tkinter import tkFileDialog root = Tkinter.Tk() newPath = tkFileDialog.askopenfilename( initialdir = "", ) The error is: Traceback (most recent call last): File "tkFileDialog_askopen bug.py", line 5, in ? newPath = tkFileDialog.askopenfilename( File "/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename return Open(**options).show() File "/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/lib-tk/tkCommonDialog.py", line 52, in show s = w.tk.call(self.command, *w._options(self.options)) _tkinter.TclError: bad directory "" The same code runs fine on unix Python 2.2.3 with unknown tcl/tk and on and unix Python 2.4.1 with tcl/tk 8.4.9. it starts out in the user's home directory as I'd expect. Mind you, I know I can use None or not specify the initialdir argument. But in my code it's a string that *might* be empty. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-07-12 08:10 Message: Logged In: YES user_id=2772 At first glance, this appears to be a bug or an incompatible change in Tk between the old version and Aqua 8.4.9. If you know the name of the 'wish' executable that uses the same version of Tcl/Tk as your Python 2.3, please check whether the tcl command tk_getOpenFile -initialdir {} fails. If it does, then this is a Tcl/Tk bug or incompatible change, and I believe this tracker item should be closed. Only if that works, but the Python equivalent doesn't, is there a reason to treat this as a bug in Python/Tkinter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470 From noreply at sourceforge.net Tue Jul 12 15:12:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 06:12:17 -0700 Subject: [ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding" Message-ID: Bugs item #1232768, was opened at 2005-07-05 16:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 Please note that this 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: Matt Smart (mcsmart) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in online docs under "5.3 Pure Embedding" Initial Comment: I'm looking at the "5.3 Pure Embedding" page: http://python.org/doc/2.4.1/ext/pure-embedding.html 1. pFunc = PyDict_GetItemString(pDict, argv[2]); - /* pFun: Borrowed reference */ + /* pFunc: Borrowed reference */ 2. The code snippet in the section starting with "After initializing the interpreter," does not follow the code in the example. It uses PyObject_GetAttrString() instead of PyObject_GetItemString(), which creates a new reference instead of borrowing one, and therefore needs a Py_XDEREF(pFunc) call that is also not in the initial example. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 15:12 Message: Logged In: YES user_id=1188172 I thought the same when I first read this report. On this HTML page, there's the large code sample at the top, and below are explanations. In the large sample the code with GetItemString and without Py_XDECREF. Both are OK, but different, and that's what the reporter's problem was. But thanks to your digging in the CVS history, I can tell that the intended code is the second version with GetAttrString. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 14:57 Message: Logged In: YES user_id=174455 Reinhold, I must confess I am confused. I'm trying to unravel what goes in in CVS with all the branches. It seems this was corrected in rev. 1.5 of embedding.tex (from 2002!?). Looking at cvs (HEAD) I also see: python/dist/src/Doc/ext/embedding.tex (line ~180): \begin{verbatim} pFunc = PyObject_GetAttrString(pModule, argv[2]); /* pFunc is a new reference */ if (pFunc && PyCallable_Check(pFunc)) { ... } Py_XDECREF(pFunc); \end{verbatim} This seems to fix the problem? Also looking at http://python.org/doc/2.4.1/ext/pure-embedding.html *today* I don't see 'Borrowed reference' and but 'a new reference' and including a PyXDEREF. Am I totally missing the point of the bug-report or is the time-machine flying again? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 13:35 Message: Logged In: YES user_id=1188172 Only the first part has been fixed. The second is beyond my decision and must be considered by someone other. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 12:59 Message: Logged In: YES user_id=174455 These seem to have been fixed already in CVS (although I can't find a duplicate report). Suggest closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 From noreply at sourceforge.net Tue Jul 12 15:18:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 06:18:41 -0700 Subject: [ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding" Message-ID: Bugs item #1232768, was opened at 2005-07-05 16:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 Please note that this 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: Matt Smart (mcsmart) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Mistakes in online docs under "5.3 Pure Embedding" Initial Comment: I'm looking at the "5.3 Pure Embedding" page: http://python.org/doc/2.4.1/ext/pure-embedding.html 1. pFunc = PyDict_GetItemString(pDict, argv[2]); - /* pFun: Borrowed reference */ + /* pFunc: Borrowed reference */ 2. The code snippet in the section starting with "After initializing the interpreter," does not follow the code in the example. It uses PyObject_GetAttrString() instead of PyObject_GetItemString(), which creates a new reference instead of borrowing one, and therefore needs a Py_XDEREF(pFunc) call that is also not in the initial example. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 15:18 Message: Logged In: YES user_id=1188172 Okay. Fixed as Doc/ext/run-func.c r1.4.20.1, r1.5. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 15:12 Message: Logged In: YES user_id=1188172 I thought the same when I first read this report. On this HTML page, there's the large code sample at the top, and below are explanations. In the large sample the code with GetItemString and without Py_XDECREF. Both are OK, but different, and that's what the reporter's problem was. But thanks to your digging in the CVS history, I can tell that the intended code is the second version with GetAttrString. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 14:57 Message: Logged In: YES user_id=174455 Reinhold, I must confess I am confused. I'm trying to unravel what goes in in CVS with all the branches. It seems this was corrected in rev. 1.5 of embedding.tex (from 2002!?). Looking at cvs (HEAD) I also see: python/dist/src/Doc/ext/embedding.tex (line ~180): \begin{verbatim} pFunc = PyObject_GetAttrString(pModule, argv[2]); /* pFunc is a new reference */ if (pFunc && PyCallable_Check(pFunc)) { ... } Py_XDECREF(pFunc); \end{verbatim} This seems to fix the problem? Also looking at http://python.org/doc/2.4.1/ext/pure-embedding.html *today* I don't see 'Borrowed reference' and but 'a new reference' and including a PyXDEREF. Am I totally missing the point of the bug-report or is the time-machine flying again? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 13:35 Message: Logged In: YES user_id=1188172 Only the first part has been fixed. The second is beyond my decision and must be considered by someone other. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 12:59 Message: Logged In: YES user_id=174455 These seem to have been fixed already in CVS (although I can't find a duplicate report). Suggest closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 From noreply at sourceforge.net Tue Jul 12 18:55:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 09:55:54 -0700 Subject: [ python-Bugs-1233799 ] tkFileDialog.askopen... fails when dir="" Message-ID: Bugs item #1233799, was opened at 2005-07-06 15:08 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.askopen... fails when dir="" Initial Comment: The following simple code fails on MacOS X 10.3 running the built- in python 2.3 and Aqua Tcl/Tk 8.4.9: import Tkinter import tkFileDialog root = Tkinter.Tk() newPath = tkFileDialog.askopenfilename( initialdir = "", ) The error is: Traceback (most recent call last): File "tkFileDialog_askopen bug.py", line 5, in ? newPath = tkFileDialog.askopenfilename( File "/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename return Open(**options).show() File "/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/lib-tk/tkCommonDialog.py", line 52, in show s = w.tk.call(self.command, *w._options(self.options)) _tkinter.TclError: bad directory "" The same code runs fine on unix Python 2.2.3 with unknown tcl/tk and on and unix Python 2.4.1 with tcl/tk 8.4.9. it starts out in the user's home directory as I'd expect. Mind you, I know I can use None or not specify the initialdir argument. But in my code it's a string that *might* be empty. ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2005-07-12 09:55 Message: Logged In: YES user_id=431773 The suggested tk command does fail: () 1 % tk_getOpenFile -initialdir {} bad directory "" so I'll report this as a Tk bug. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-07-12 06:10 Message: Logged In: YES user_id=2772 At first glance, this appears to be a bug or an incompatible change in Tk between the old version and Aqua 8.4.9. If you know the name of the 'wish' executable that uses the same version of Tcl/Tk as your Python 2.3, please check whether the tcl command tk_getOpenFile -initialdir {} fails. If it does, then this is a Tcl/Tk bug or incompatible change, and I believe this tracker item should be closed. Only if that works, but the Python equivalent doesn't, is there a reason to treat this as a bug in Python/Tkinter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470 From noreply at sourceforge.net Tue Jul 12 19:32:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 10:32:08 -0700 Subject: [ python-Bugs-1233799 ] tkFileDialog.askopen... fails when dir="" Message-ID: Bugs item #1233799, was opened at 2005-07-07 00:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter >Group: 3rd Party >Status: Closed Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.askopen... fails when dir="" Initial Comment: The following simple code fails on MacOS X 10.3 running the built- in python 2.3 and Aqua Tcl/Tk 8.4.9: import Tkinter import tkFileDialog root = Tkinter.Tk() newPath = tkFileDialog.askopenfilename( initialdir = "", ) The error is: Traceback (most recent call last): File "tkFileDialog_askopen bug.py", line 5, in ? newPath = tkFileDialog.askopenfilename( File "/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename return Open(**options).show() File "/System/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/lib-tk/tkCommonDialog.py", line 52, in show s = w.tk.call(self.command, *w._options(self.options)) _tkinter.TclError: bad directory "" The same code runs fine on unix Python 2.2.3 with unknown tcl/tk and on and unix Python 2.4.1 with tcl/tk 8.4.9. it starts out in the user's home directory as I'd expect. Mind you, I know I can use None or not specify the initialdir argument. But in my code it's a string that *might* be empty. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 19:32 Message: Logged In: YES user_id=1188172 Closing this as 3rd party, then. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2005-07-12 18:55 Message: Logged In: YES user_id=431773 The suggested tk command does fail: () 1 % tk_getOpenFile -initialdir {} bad directory "" so I'll report this as a Tk bug. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-07-12 15:10 Message: Logged In: YES user_id=2772 At first glance, this appears to be a bug or an incompatible change in Tk between the old version and Aqua 8.4.9. If you know the name of the 'wish' executable that uses the same version of Tcl/Tk as your Python 2.3, please check whether the tcl command tk_getOpenFile -initialdir {} fails. If it does, then this is a Tcl/Tk bug or incompatible change, and I believe this tracker item should be closed. Only if that works, but the Python equivalent doesn't, is there a reason to treat this as a bug in Python/Tkinter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470 From noreply at sourceforge.net Tue Jul 12 20:07:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 11:07:41 -0700 Subject: [ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars Message-ID: Bugs item #1175396, was opened at 2005-04-02 15:14 Message generated for change (Comment added) made by vrmeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 Please note that this message 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: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter D?rwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line.... Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) ---------------------------------------------------------------------- Comment By: Alan Meyer (vrmeyer) Date: 2005-07-12 18:07 Message: Logged In: YES user_id=338015 Hello doerwalter, Our thanks to you and to glchapman for working on this bug. I think the project I am working on may have run into this bug while attempting to use the python COM client wrappers for ADO on Win32. We saw the problem in Python 2.4.1, but not 2.4 or 2.3.5. Do you have any projection for when the fix will make it into the stable distribution? Our production is running on 2.3.5. If it looks like a long while before the fix is distributed, we may upgrade to 2.4.0. Otherwise we'll stick with 2.3.5 and wait. Thanks again. Alan ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 14:20 Message: Logged In: YES user_id=89016 > > 1) How do we handle the problem of a truncated line, if the > > data comes from the charbuffer instead of being read from > > > the stream? > > > > My suggestion is to make the top of the loop look like: > > > > while True: > > havecharbuffer = bool(self.charbuffer) > > > > And then the break condition (when no line break found) > > should be: > > > > # we didn't get anything or this was our only try > > if not data or (size is not None and not havecharbuffer): > > > > (too many negatives in that). Anyway, the idea is that, if > > size specified, there will be at most one read of the > > underlying stream (using the size). So if you enter the > > loop with a charbuffer, and that charbuffer does not have a > > line break, then you redo the loop once (the second time it > > will break, because havecharbuffer will be False). This makes sense. However, with the current state of the tokenizer this might be to dangerous, because the resulting line might be twice as long. So fixing the tokenizer should be the first step. BTW, your patch fixes the problems with the fix for #1178484, so I think I'm going to apply the patch in the next days, if there are no objections. > > Also, not sure about this, but should the size parameter > > default to -1 (to keep it in sync with read)? None seems to be a better default from an API viewpoint, but -1 is better for "C compatibility". > > As to issue 2, it looks like it should be possible to get > > the line number right, because the UnicodeDecodeError > > exception object has all the necessary information in it > > (including the original string). I think this should be > > done by fp_readl (in tokenizer.c). The patch for #1178484 fixes this. Combined with this patch I think we're in good shape. > > By the way, using a findlinebreak function (using sre) turns > > out to be slower than splitting/joining when no size is > > specified (which I assume will be the overwhelmingly most > > common case), so that turned out to be a bad idea on my part. Coding this on the C level and using Py_UNICODE_ISLINEBREAK() should be the fastest version, but I don't know if this is worth it. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-23 16:46 Message: Logged In: YES user_id=86307 > 1) How do we handle the problem of a truncated line, if the > data comes from the charbuffer instead of being read from > the stream? My suggestion is to make the top of the loop look like: while True: havecharbuffer = bool(self.charbuffer) And then the break condition (when no line break found) should be: # we didn't get anything or this was our only try if not data or (size is not None and not havecharbuffer): (too many negatives in that). Anyway, the idea is that, if size specified, there will be at most one read of the underlying stream (using the size). So if you enter the loop with a charbuffer, and that charbuffer does not have a line break, then you redo the loop once (the second time it will break, because havecharbuffer will be False). Also, not sure about this, but should the size parameter default to -1 (to keep it in sync with read)? As to issue 2, it looks like it should be possible to get the line number right, because the UnicodeDecodeError exception object has all the necessary information in it (including the original string). I think this should be done by fp_readl (in tokenizer.c). By the way, using a findlinebreak function (using sre) turns out to be slower than splitting/joining when no size is specified (which I assume will be the overwhelmingly most common case), so that turned out to be a bad idea on my part. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-21 21:55 Message: Logged In: YES user_id=89016 OK, I've checked in the following: Lib/codecs.py 1.44 Lib/test/test_codecs.py 1.23 Lib/codecs.py 1.35.2.7 Lib/test/test_codecs.py 1.15.2.5 with the following changes as suggested by glchapman: If a chunk read has a trailing "\r", read one more character even if the user has passed a size parameter. Remove the atcr logic. This should fix most of the problems. There are three open issues: 1) How do we handle the problem of a truncated line, if the data comes from the charbuffer instead of being read from the stream? 2) How do we handle error reporting? The buffering code might read more data than the current line. If this data has a decoding error the caller might report a wrong line number. (See bug #1178484) 3) Fixing the tokenizer. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-15 18:16 Message: Logged In: YES user_id=89016 The current readline() is implemented so that even if the complete line ending (i.e. '\r\n') can't be read within size bytes, at least something that might work as a line end (i.e. '\r') is available at the end of the string, so that the user knowns that the line is complete. The atcr members makes sure that the '\n' that is read next isn't misinterpreted as another line. Unfortunately the import mechanisn doesn't work that way: It demands a '\n' as line terminator and will continue reading if it only finds the '\r'. This means that the '\n' will be skipped and the import mechanisn treats those two lines as one. IMHO the best solution would be the read the extra character even if size is None, as glchapman suggested, so the above situation would really only happen if the last character from the stream is '\r'. I think the tokenizer should be able to survive this. What it didn't survive in 2.4 was that readline() tried to get it's hand on a complete line even if the length of the line was way bigger than the size passed in. If we remove the "size is None" restriction from the current code, then I think we should remove the atcr logic too, because it could only happen under exceptional circumstances and the old handling might be better for those users that don't recognize '\r' as a line end. But in any case the tokenizer should be fixed to be able to handle any line length returned from readline(). I'd really like to get a review by Martin v. L?wis of glchapman's patch #1101726. Of course the simplest solution would be: "If you want a complete line, don't pass a size parameter to readline()". I don't know if it would make sense to change the PEP263 machinery to support this. The other problem is if readline() returns data from the charbuffer. I don't really see how this can be fixed. We might call read() with a size parameter even if there are characters in the charbuffer, but what happens if the user calls readline(size=100000) first and then readline(size=10)? The first readline() call might put a very long string into the charbuffer and then the second call will return a unicode string whose length is in no way correlated to the size parameter. (This happens even even with the current code of course, so the message should be: Don't trust the size parameter, it only tells the underlying stream how many bytes to read (approximately), it's doesn't tell you *anything* about the amount of data returned.). This was different in 2.3.x, because the readline() method of the underlying stream was used, which handled this properly, but only worked if an encoded linefeed was recognizable as a normal 8bit '\n' linefeed by the underlying readline() (i.e. the UTF-16 encodings didn't work). ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-14 23:25 Message: Logged In: YES user_id=86307 I think the foo2.py from 1163244 is probably the same bug; at any rate, the reason for it is that a \r is at the beginning of the last line when read in by decoding_fgets. I have simpler test file which shows the bug which I'll email to Walter (you basically just have to get a \r as the last character in the block read by StreamReader, so that atcr will be true). The problem is caused by StreamReader.readline doing: if self.atcr and data.startswith(u"\n"): data = data[1:] since the tokenizer relies on '\n' as the line break character, but it will never see the '\n' removed by the above. FWIW (not much), I think the 2.4 StreamReader.readline actually made more sense than the current code, although a few changes would seem useful (see below). I don't think it is particularly useful to treat the size parameter as a fixed maximum number of bytes to read, since the number of bytes read has no fixed relationship to the number of decoded unicode characters (and also, in the case of the tokenizer, no fixed relationship to the number of bytes of encoded utf8). Also, given the current code, the size parameter is effectively ignored if there is a charbuffer: if you have 5 characters sitting in the charbuffer and use a size of 0x1FF, you only get back the 5 characters, even if they do not end in a linebreak. For the tokenizer, this means an unnecessary PyMem_RESIZE and an extra call to decoding_readline roughly every BUFSIZ bytes in the file (since the tokenizer assumes failure to fetch a complete line means its buffer is too small, whereas in fact it was caused by an incomplete line being stored in the StreamReader's charbuffer). As to changes from 2.4, if the unicode object were to add a findlinebreak method which returns the index of the first character for which Py_UNICODE_ISLINEBREAK is true, readline could use that instead of find("\n"). If it used such a method, readline would also need to explicitly handle a "\r\n" sequence, including a potential read(1) if a '\r' appears at the end of the data (in the case where size is not None). Of course, one problem with that idea is it requires a new method, which may not be allowed until 2.5, and the 2.4.1 behavior definitely needs to be fixed some way. (Interestingly, it looks to me like sre has everything necessary for searching for unicode linebreaks except syntax with which to express the idea in a pattern (maybe I'm missing something, but I can't find a way to get a compiled pattern to emit CATEGORY_UNI_LINEBREAK).) ---------------------------------------------------------------------- Comment By: Michal Rydlo (mmm) Date: 2005-04-14 22:04 Message: Logged In: YES user_id=65460 foo2.py from #1163244 fails to import. Not being expert in Python internals I hope it is due to this bug. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-11 21:42 Message: Logged In: YES user_id=89016 OK, I'm reopening to bug report. I didn't manage to install pythondoc. cElementTree complains about: No such file or directory: './pyconfig.h'. Can you provide a simple Python file that fails when imported? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-09 22:47 Message: Logged In: YES user_id=86307 Sorry to comment on a closed report, but perhaps this fix should not be limited only to cases where size is None. Today, I ran into a spurious syntax error when trying to import pythondoc (from http://effbot.org/downloads/pythondoc-2.1b3-20050325.zip). It turned out a \r was ending up in what looked to the parser like the middle of a line, presumably because a \n was dropped. Anyway, I applied the referenced patch to 2.4.1, except I left out the "size is None" condition, since I knew the tokenizer passes in a size param. With that change pythondoc import successfully. (Also, I just ran the test suite and nothing broke.) Since the size parameter is already documented as being passed to StreamReader.read (in codecs.py -- the HTML documentation needs to be updated), and since StreamReader.read says size is an approximate maximum, perhaps it's OK to read one extra byte. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-04 22:01 Message: Logged In: YES user_id=89016 Checked in a fix as: Lib/codecs.py 1.42/1.43 Lib/test/test_codecs.py 1.22 Lib/codecs.py 1.35.2.6 Lib/test/test_codecs.py 1.15.2.4 Are you really sure, that the fix for #1098990 is not in 2.4.1? According to the tracker for #1098990 the fix was in lib/codecs.py revision 1.35.2.2 and revision 1.35.2.3 is the one that got the r241c1 tag, so the fix should be in 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 From noreply at sourceforge.net Tue Jul 12 20:59:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 11:59:41 -0700 Subject: [ python-Bugs-1236906 ] email.Generator traceback in forwarded msg Message-ID: Bugs item #1236906, was opened at 2005-07-12 13: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=1236906&group_id=5470 Please note that this message 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: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: email.Generator traceback in forwarded msg Initial Comment: The SpamBayes sb_unheader app uses the email package to dump out a copy of a message with user-specified headers removed. The email.Generator.Generator class is barfing on the attached message. I haven't had a chance to look into it yet, but I suspect it's a problem in the email package, not the sb_unheader program. Here's the traceback I see. This is with a Python built from CVS within the last couple days. Traceback (most recent call last): File "/Users/skip/local/bin/sb_unheader.py", line 144, in ? main(sys.argv[1:]) File "/Users/skip/local/bin/sb_unheader.py", line 139, in main process_mailbox(f, dosa, pats) File "/Users/skip/local/bin/sb_unheader.py", line 86, in process_mailbox gen.flatten(msg, unixfrom=1) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 82, in flatten self._write(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 113, in _write self._dispatch(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 139, in _dispatch meth(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 273, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/Users/skip/local/lib/python2.5/email/Message.py", line 183, in get_payload raise TypeError('Expected list, got %s' % type(self._payload)) TypeError: Expected list, got montanaro:tmp% type tradelink tradelink is aliased to `ssh -C -X loginhost.trdlnk.com' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 From noreply at sourceforge.net Tue Jul 12 21:04:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 12:04:56 -0700 Subject: [ python-Bugs-1236906 ] email.Generator traceback in forwarded msg Message-ID: Bugs item #1236906, was opened at 2005-07-12 14:59 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 Please note that this message 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: Skip Montanaro (montanaro) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generator traceback in forwarded msg Initial Comment: The SpamBayes sb_unheader app uses the email package to dump out a copy of a message with user-specified headers removed. The email.Generator.Generator class is barfing on the attached message. I haven't had a chance to look into it yet, but I suspect it's a problem in the email package, not the sb_unheader program. Here's the traceback I see. This is with a Python built from CVS within the last couple days. Traceback (most recent call last): File "/Users/skip/local/bin/sb_unheader.py", line 144, in ? main(sys.argv[1:]) File "/Users/skip/local/bin/sb_unheader.py", line 139, in main process_mailbox(f, dosa, pats) File "/Users/skip/local/bin/sb_unheader.py", line 86, in process_mailbox gen.flatten(msg, unixfrom=1) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 82, in flatten self._write(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 113, in _write self._dispatch(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 139, in _dispatch meth(msg) File "/Users/skip/local/lib/python2.5/email/Generator.py", line 273, in _handle_message g.flatten(msg.get_payload(0), unixfrom=False) File "/Users/skip/local/lib/python2.5/email/Message.py", line 183, in get_payload raise TypeError('Expected list, got %s' % type(self._payload)) TypeError: Expected list, got montanaro:tmp% type tradelink tradelink is aliased to `ssh -C -X loginhost.trdlnk.com' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470 From noreply at sourceforge.net Tue Jul 12 21:53:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 12:53:53 -0700 Subject: [ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars Message-ID: Bugs item #1175396, was opened at 2005-04-02 06:14 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 Please note that this message 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: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter D?rwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line.... Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-07-12 11:53 Message: Logged In: YES user_id=86307 Build 204 of pywin32 has a workaround for bug 1163244 which should also avoid this bug: it leaves out the encoding notation in generated COM wrapper files (so loading will not involve the codecs module). If your wrapper files don't need extended characters (I don't think ADO does), you might want to give that a shot. ---------------------------------------------------------------------- Comment By: Alan Meyer (vrmeyer) Date: 2005-07-12 10:07 Message: Logged In: YES user_id=338015 Hello doerwalter, Our thanks to you and to glchapman for working on this bug. I think the project I am working on may have run into this bug while attempting to use the python COM client wrappers for ADO on Win32. We saw the problem in Python 2.4.1, but not 2.4 or 2.3.5. Do you have any projection for when the fix will make it into the stable distribution? Our production is running on 2.3.5. If it looks like a long while before the fix is distributed, we may upgrade to 2.4.0. Otherwise we'll stick with 2.3.5 and wait. Thanks again. Alan ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-05-16 06:20 Message: Logged In: YES user_id=89016 > > 1) How do we handle the problem of a truncated line, if the > > data comes from the charbuffer instead of being read from > > > the stream? > > > > My suggestion is to make the top of the loop look like: > > > > while True: > > havecharbuffer = bool(self.charbuffer) > > > > And then the break condition (when no line break found) > > should be: > > > > # we didn't get anything or this was our only try > > if not data or (size is not None and not havecharbuffer): > > > > (too many negatives in that). Anyway, the idea is that, if > > size specified, there will be at most one read of the > > underlying stream (using the size). So if you enter the > > loop with a charbuffer, and that charbuffer does not have a > > line break, then you redo the loop once (the second time it > > will break, because havecharbuffer will be False). This makes sense. However, with the current state of the tokenizer this might be to dangerous, because the resulting line might be twice as long. So fixing the tokenizer should be the first step. BTW, your patch fixes the problems with the fix for #1178484, so I think I'm going to apply the patch in the next days, if there are no objections. > > Also, not sure about this, but should the size parameter > > default to -1 (to keep it in sync with read)? None seems to be a better default from an API viewpoint, but -1 is better for "C compatibility". > > As to issue 2, it looks like it should be possible to get > > the line number right, because the UnicodeDecodeError > > exception object has all the necessary information in it > > (including the original string). I think this should be > > done by fp_readl (in tokenizer.c). The patch for #1178484 fixes this. Combined with this patch I think we're in good shape. > > By the way, using a findlinebreak function (using sre) turns > > out to be slower than splitting/joining when no size is > > specified (which I assume will be the overwhelmingly most > > common case), so that turned out to be a bad idea on my part. Coding this on the C level and using Py_UNICODE_ISLINEBREAK() should be the fastest version, but I don't know if this is worth it. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-23 08:46 Message: Logged In: YES user_id=86307 > 1) How do we handle the problem of a truncated line, if the > data comes from the charbuffer instead of being read from > the stream? My suggestion is to make the top of the loop look like: while True: havecharbuffer = bool(self.charbuffer) And then the break condition (when no line break found) should be: # we didn't get anything or this was our only try if not data or (size is not None and not havecharbuffer): (too many negatives in that). Anyway, the idea is that, if size specified, there will be at most one read of the underlying stream (using the size). So if you enter the loop with a charbuffer, and that charbuffer does not have a line break, then you redo the loop once (the second time it will break, because havecharbuffer will be False). Also, not sure about this, but should the size parameter default to -1 (to keep it in sync with read)? As to issue 2, it looks like it should be possible to get the line number right, because the UnicodeDecodeError exception object has all the necessary information in it (including the original string). I think this should be done by fp_readl (in tokenizer.c). By the way, using a findlinebreak function (using sre) turns out to be slower than splitting/joining when no size is specified (which I assume will be the overwhelmingly most common case), so that turned out to be a bad idea on my part. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-21 13:55 Message: Logged In: YES user_id=89016 OK, I've checked in the following: Lib/codecs.py 1.44 Lib/test/test_codecs.py 1.23 Lib/codecs.py 1.35.2.7 Lib/test/test_codecs.py 1.15.2.5 with the following changes as suggested by glchapman: If a chunk read has a trailing "\r", read one more character even if the user has passed a size parameter. Remove the atcr logic. This should fix most of the problems. There are three open issues: 1) How do we handle the problem of a truncated line, if the data comes from the charbuffer instead of being read from the stream? 2) How do we handle error reporting? The buffering code might read more data than the current line. If this data has a decoding error the caller might report a wrong line number. (See bug #1178484) 3) Fixing the tokenizer. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-15 10:16 Message: Logged In: YES user_id=89016 The current readline() is implemented so that even if the complete line ending (i.e. '\r\n') can't be read within size bytes, at least something that might work as a line end (i.e. '\r') is available at the end of the string, so that the user knowns that the line is complete. The atcr members makes sure that the '\n' that is read next isn't misinterpreted as another line. Unfortunately the import mechanisn doesn't work that way: It demands a '\n' as line terminator and will continue reading if it only finds the '\r'. This means that the '\n' will be skipped and the import mechanisn treats those two lines as one. IMHO the best solution would be the read the extra character even if size is None, as glchapman suggested, so the above situation would really only happen if the last character from the stream is '\r'. I think the tokenizer should be able to survive this. What it didn't survive in 2.4 was that readline() tried to get it's hand on a complete line even if the length of the line was way bigger than the size passed in. If we remove the "size is None" restriction from the current code, then I think we should remove the atcr logic too, because it could only happen under exceptional circumstances and the old handling might be better for those users that don't recognize '\r' as a line end. But in any case the tokenizer should be fixed to be able to handle any line length returned from readline(). I'd really like to get a review by Martin v. L?wis of glchapman's patch #1101726. Of course the simplest solution would be: "If you want a complete line, don't pass a size parameter to readline()". I don't know if it would make sense to change the PEP263 machinery to support this. The other problem is if readline() returns data from the charbuffer. I don't really see how this can be fixed. We might call read() with a size parameter even if there are characters in the charbuffer, but what happens if the user calls readline(size=100000) first and then readline(size=10)? The first readline() call might put a very long string into the charbuffer and then the second call will return a unicode string whose length is in no way correlated to the size parameter. (This happens even even with the current code of course, so the message should be: Don't trust the size parameter, it only tells the underlying stream how many bytes to read (approximately), it's doesn't tell you *anything* about the amount of data returned.). This was different in 2.3.x, because the readline() method of the underlying stream was used, which handled this properly, but only worked if an encoded linefeed was recognizable as a normal 8bit '\n' linefeed by the underlying readline() (i.e. the UTF-16 encodings didn't work). ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-14 15:25 Message: Logged In: YES user_id=86307 I think the foo2.py from 1163244 is probably the same bug; at any rate, the reason for it is that a \r is at the beginning of the last line when read in by decoding_fgets. I have simpler test file which shows the bug which I'll email to Walter (you basically just have to get a \r as the last character in the block read by StreamReader, so that atcr will be true). The problem is caused by StreamReader.readline doing: if self.atcr and data.startswith(u"\n"): data = data[1:] since the tokenizer relies on '\n' as the line break character, but it will never see the '\n' removed by the above. FWIW (not much), I think the 2.4 StreamReader.readline actually made more sense than the current code, although a few changes would seem useful (see below). I don't think it is particularly useful to treat the size parameter as a fixed maximum number of bytes to read, since the number of bytes read has no fixed relationship to the number of decoded unicode characters (and also, in the case of the tokenizer, no fixed relationship to the number of bytes of encoded utf8). Also, given the current code, the size parameter is effectively ignored if there is a charbuffer: if you have 5 characters sitting in the charbuffer and use a size of 0x1FF, you only get back the 5 characters, even if they do not end in a linebreak. For the tokenizer, this means an unnecessary PyMem_RESIZE and an extra call to decoding_readline roughly every BUFSIZ bytes in the file (since the tokenizer assumes failure to fetch a complete line means its buffer is too small, whereas in fact it was caused by an incomplete line being stored in the StreamReader's charbuffer). As to changes from 2.4, if the unicode object were to add a findlinebreak method which returns the index of the first character for which Py_UNICODE_ISLINEBREAK is true, readline could use that instead of find("\n"). If it used such a method, readline would also need to explicitly handle a "\r\n" sequence, including a potential read(1) if a '\r' appears at the end of the data (in the case where size is not None). Of course, one problem with that idea is it requires a new method, which may not be allowed until 2.5, and the 2.4.1 behavior definitely needs to be fixed some way. (Interestingly, it looks to me like sre has everything necessary for searching for unicode linebreaks except syntax with which to express the idea in a pattern (maybe I'm missing something, but I can't find a way to get a compiled pattern to emit CATEGORY_UNI_LINEBREAK).) ---------------------------------------------------------------------- Comment By: Michal Rydlo (mmm) Date: 2005-04-14 14:04 Message: Logged In: YES user_id=65460 foo2.py from #1163244 fails to import. Not being expert in Python internals I hope it is due to this bug. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-11 13:42 Message: Logged In: YES user_id=89016 OK, I'm reopening to bug report. I didn't manage to install pythondoc. cElementTree complains about: No such file or directory: './pyconfig.h'. Can you provide a simple Python file that fails when imported? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-04-09 14:47 Message: Logged In: YES user_id=86307 Sorry to comment on a closed report, but perhaps this fix should not be limited only to cases where size is None. Today, I ran into a spurious syntax error when trying to import pythondoc (from http://effbot.org/downloads/pythondoc-2.1b3-20050325.zip). It turned out a \r was ending up in what looked to the parser like the middle of a line, presumably because a \n was dropped. Anyway, I applied the referenced patch to 2.4.1, except I left out the "size is None" condition, since I knew the tokenizer passes in a size param. With that change pythondoc import successfully. (Also, I just ran the test suite and nothing broke.) Since the size parameter is already documented as being passed to StreamReader.read (in codecs.py -- the HTML documentation needs to be updated), and since StreamReader.read says size is an approximate maximum, perhaps it's OK to read one extra byte. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-04 14:01 Message: Logged In: YES user_id=89016 Checked in a fix as: Lib/codecs.py 1.42/1.43 Lib/test/test_codecs.py 1.22 Lib/codecs.py 1.35.2.6 Lib/test/test_codecs.py 1.15.2.4 Are you really sure, that the fix for #1098990 is not in 2.4.1? According to the tracker for #1098990 the fix was in lib/codecs.py revision 1.35.2.2 and revision 1.35.2.3 is the one that got the r241c1 tag, so the fix should be in 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 From noreply at sourceforge.net Tue Jul 12 22:18:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 13:18:28 -0700 Subject: [ python-Bugs-1236090 ] Carbon.FSSpec.as_pathname() crashes Message-ID: Bugs item #1236090, was opened at 2005-07-11 16:12 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 8 Submitted By: Michael Hudson (mwh) Assigned to: Jack Jansen (jackjansen) >Summary: Carbon.FSSpec.as_pathname() crashes Initial Comment: There's something peculiar in the land of bgen-ed wrappers: $ ./python.exe Python 2.5a0 (#1, Jul 11 2005, 13:21:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Carbon.File [45313 refs] >>> Carbon.File.FSSpec(os.curdir).as_pathname() Segmentation fault ("make test" also crashes). This is on 10.3.9. My first investigations with gdb didn't reveal anything that made much sense, so it *might* be a compiler bug. At any rate, it didn't do this a few weeks ago... ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-07-12 22:18 Message: Logged In: YES user_id=45365 The problem appears to be in as_pathname(). Investigating... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&group_id=5470 From noreply at sourceforge.net Tue Jul 12 23:26:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 14:26:12 -0700 Subject: [ python-Bugs-1236090 ] Carbon.FSSpec.as_pathname() crashes Message-ID: Bugs item #1236090, was opened at 2005-07-11 16:12 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Michael Hudson (mwh) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.FSSpec.as_pathname() crashes Initial Comment: There's something peculiar in the land of bgen-ed wrappers: $ ./python.exe Python 2.5a0 (#1, Jul 11 2005, 13:21:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Carbon.File [45313 refs] >>> Carbon.File.FSSpec(os.curdir).as_pathname() Segmentation fault ("make test" also crashes). This is on 10.3.9. My first investigations with gdb didn't reveal anything that made much sense, so it *might* be a compiler bug. At any rate, it didn't do this a few weeks ago... ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-07-12 23:26 Message: Logged In: YES user_id=45365 Argh! It turns out that patch #1035255 was incomplete: it patched _Filemodule.c, but not filesupport.py (bad Bob, no cookie:-) So, when I regenerated _Filemodule.c last week FSSpec.as_pathname() still called FSSpec_as_pathname, in stead of _FSSpec_as_pathname (note the subtle difference, which I consequently overlooked). This resulted in an infinite loop. Fixed in _Filemodule.c rev. 1.25, filesupport.py rev. 1.22. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-07-12 22:18 Message: Logged In: YES user_id=45365 The problem appears to be in as_pathname(). Investigating... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&group_id=5470 From noreply at sourceforge.net Wed Jul 13 00:00:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 15:00:15 -0700 Subject: [ python-Bugs-1089395 ] segfault/assert in tokenizer Message-ID: Bugs item #1089395, was opened at 2004-12-21 23:02 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089395&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L?wis (loewis) Summary: segfault/assert in tokenizer Initial Comment: The attached script fail.py (with the attached codec evilascii.py) leads to a segfault in both Python 2.3 and 2.4. With a debug build I get: python: Parser/tokenizer.c:367: fp_readl: Assertion `strlen(str) < (size_t)size' failed. Aborted Assigning to Martin, because this seems to be PEP 263 related. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-07-13 00:00 Message: Logged In: YES user_id=89016 OK, patch www.python.org/sf/1101726 has been applied. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-01-13 16:47 Message: Logged In: YES user_id=86307 I just posted a patch for this here: www.python.org/sf/1101726 I'd appreciate any comments/corrections. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089395&group_id=5470 From noreply at sourceforge.net Wed Jul 13 00:51:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 15:51:15 -0700 Subject: [ python-Bugs-1237015 ] Missing sk_SK in windows_locale Message-ID: Bugs item #1237015, was opened at 2005-07-13 00:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237015&group_id=5470 Please note that this 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: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: Missing sk_SK in windows_locale Initial Comment: Please, could you add sk_SK locale to windows_locale array in module locale? Corresponding entry should look like: 0x041b: "sk_SK", # Slovak Information about language ID taken is from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237015&group_id=5470 From noreply at sourceforge.net Wed Jul 13 06:36:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jul 2005 21:36:10 -0700 Subject: [ python-Bugs-1229788 ] Bus error in extension with gcc 3.3 Message-ID: Bugs item #1229788, was opened at 2005-06-30 03:43 Message generated for change (Comment added) made by esrever_otua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Robinson (garyrob) Assigned to: Nobody/Anonymous (nobody) Summary: Bus error in extension with gcc 3.3 Initial Comment: This text contains a c module with 4 versions of the same extremely simple function. All they do is return a float double to python. On Windows I have received a report from someone who can built the module, imported it into Python, and ran it successfully. It has also been reported that there is no problem when the extension is compiled with gcc 4.0 on OS X. However, on OS X, if the extension is compiled with gcc 3.3, the 4th of the 4 function results in a bus error: >>> from check import * fun0() 411.0 >>> fun1() 534.30000000000007 >>> fun2() 411.0 >>> fun3() Bus error I originally reported this on the C++ sig's mail list. They suggested I try dev-python. Scott David Daniels on that list helped me refine some test cases and verified that they all worked on Windows. Along the way it was suggested that I post a bug report. So this is it. The code follows: #include "Python.h" static double value = 411.0; static PyObject * fun0(PyObject *self, PyObject *args) { if (!PyArg_ParseTuple(args, "", NULL)) return NULL; return Py_BuildValue("d", value); } static PyObject * fun1(PyObject *self, PyObject *args) { return Py_BuildValue("d", 1.3*value); } static PyObject * fun2(PyObject *self, PyObject *args) { return PyFloat_FromDouble(value); } static PyObject * fun3(PyObject *self, PyObject *args) { return Py_BuildValue("d", value); } static PyMethodDef TestMethods[] = { {"fun0", fun0, METH_VARARGS, "Read args and return value"}, {"fun1", fun1, METH_VARARGS, "Return value multiplied inline by 1.3"}, {"fun2", fun2, METH_VARARGS, "Return value using PyFloat_FromDouble"}, {"fun3", fun3, METH_VARARGS, "Return value using Py_BuildValue without reading args -- causes bus error on OS X Panther with XCode 1.5 installed"}, {NULL, NULL, 0, NULL} /* Sentinel */ }; PyMODINIT_FUNC initcheck(void) { PyObject *module; module = Py_InitModule3("check", TestMethods, "extension module with three functions."); if (module) { PyModule_AddStringConstant(module, "__version__", "0.02"); } } ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-13 16:36 Message: Logged In: YES user_id=567623 Bus errors are generally caused by unaligned memory accesses, or by attempts to read past the end of a file-descriptor (or something along those lines). This sounds like a gcc bug rather than a Python bug. Can I suggest changing your compiler flags and experimenting with things like different -O levels? (-O3, -O1, etc) to see if it makes a difference... Also, you may want to raise a bug with gcc (although I've no idea how seriously they would take it :( ). Finally, what version of gcc is Python compiled with on Panther? There may be a conflict there (once again, different optimisations might be the problem). Anyhow, just my random thoughts, D ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-07-02 15:13 Message: Logged In: YES user_id=593130 I understand that you got advice to post, but I strongly doubt that core Python code is involved for three reasons. 1. On the Unix I used, bus errors were much rarer and esoteric than segmentation violations (from bad pointers). But maybe BSD-derived OSX is different. 2. The only difference between fun1 that works and fun3 that doesn't, seems to be how the arg in computed. The receiving function only gets a value (which it copies) and does not know its history. 3. You report that upgrading the compiler fixes the problem. (So why not just do that?) If you want to experiment more, redo fun1 and fun3 with 'value' replaced by its literal value. Then redo again with value = 534.30000000000007 instead of 411 and change arg in fun1 to value/1.3 instead of 1.3*value. About stack trace: On unix (of 15 years ago), program crashes usually resulted in a file called 'core' added to either the startup or current working directory. A debugger program could extract a stack trace, which was more readable if the executable still had the symbol table attached and not stripped. I don't know equivalent for OSX, but I found it very helpful for debugging. ---------------------------------------------------------------------- Comment By: Gary Robinson (garyrob) Date: 2005-07-01 08:15 Message: Logged In: YES user_id=136420 It was reproduced by someone with Python 2.4 and gcc 3.3. So it is not my machine. As to closing it, a couple of people in the python C++ sig and python-dev suggested I post it here as a bug, so I did. I'm just doing what was requested of me. I don't mind if someone else feels it should be closed without doing anything about it, but I don't think everyone would agree with that action. As for stack trace, I don't know how to look for that. All I got was the "bus error" message. If you tell me what to look for I'll look for it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-07-01 08:05 Message: Logged In: YES user_id=593130 Do you have any reason to think the bug is in Python rather than the older version of gcc? Or OSX? Or even your computer? If not, please consider closing. Does OSX give you a stack trace? If so,what is executing when the crash occurs? In fun3, Py_BuildValue, or somehow inbewteen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470 From noreply at sourceforge.net Wed Jul 13 18:45:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 09:45:45 -0700 Subject: [ python-Feature Requests-1237678 ] add a note to eval and exec to not use it when possible Message-ID: Feature Requests item #1237678, was opened at 2005-07-13 18:45 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=1237678&group_id=5470 Please note that this 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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: add a note to eval and exec to not use it when possible Initial Comment: The docs for eval and exec should have pointers how to avoid them, by e.g. using locals(), globals(), getattr, setattr etc. Many questions pop up on c.l.py which could be answered by this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237678&group_id=5470 From noreply at sourceforge.net Wed Jul 13 18:48:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 09:48:21 -0700 Subject: [ python-Feature Requests-1237680 ] add dedent() string method Message-ID: Feature Requests item #1237680, was opened at 2005-07-13 18:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237680&group_id=5470 Please note that this message 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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: add dedent() string method Initial Comment: textwrap.dedent() is very useful for in-code multi-line string literals. However, as it is "hidden" in a module it does not really fit in, people don't use it and instead propose new string literal syntax for "dedented". str.dedent with an efficient C implementation would solve this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237680&group_id=5470 From noreply at sourceforge.net Wed Jul 13 19:06:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 10:06:02 -0700 Subject: [ python-Bugs-1237697 ] link path probs on OSX re: Tcl, Tk & fink's /sw Message-ID: Bugs item #1237697, was opened at 2005-07-13 10: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=1237697&group_id=5470 Please note that this 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: blakers (blakers) Assigned to: Nobody/Anonymous (nobody) Summary: link path probs on OSX re: Tcl, Tk & fink's /sw Initial Comment: hi all, i'm bldg Python 2.4.1 on OSX 10.4.1 ... i've installed a late version of Tcl/Tk framework in: /Library/Frameworks/Tcl.framework /Library/Frameworks/Tk.framework iiuc, these frameworks/libs are SUPPOSED to be searched PRIOR to / System/Library/Frameworks ... i've installed the Fink dev env in "/sw" the Fink ev is 'disabled' o my box ... i.e., "/sw" is NOT in my path ... that said, the Python build 'insists' on building against: (1) the /System/... Tcl & Tk frameworks (2) libs/includes in /sw/... (e.g., ndbm.h ...) correcting the problem is INSENSITIVE to discreet inclusion of /Library/ Frameworks in LD_LIBRARY_PATH/DYLD_LIBRARY_PATH only the build time spec'n of: setenv LDFLAGS "-L/Library/Frameworks -framework Tcl -framework Tk" seems to do the trick ... as for /sw, only a: mv /sw /swTMP ( ... build ...) mv /swTMP /sw seems to work. cheers, richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237697&group_id=5470 From noreply at sourceforge.net Wed Jul 13 19:56:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 10:56:15 -0700 Subject: [ python-Bugs-1237697 ] link path probs on OSX re: Tcl, Tk & fink's /sw Message-ID: Bugs item #1237697, was opened at 2005-07-13 10:06 Message generated for change (Comment added) made by blakers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237697&group_id=5470 Please note that this 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: 7 Submitted By: blakers (blakers) Assigned to: Nobody/Anonymous (nobody) Summary: link path probs on OSX re: Tcl, Tk & fink's /sw Initial Comment: hi all, i'm bldg Python 2.4.1 on OSX 10.4.1 ... i've installed a late version of Tcl/Tk framework in: /Library/Frameworks/Tcl.framework /Library/Frameworks/Tk.framework iiuc, these frameworks/libs are SUPPOSED to be searched PRIOR to / System/Library/Frameworks ... i've installed the Fink dev env in "/sw" the Fink ev is 'disabled' o my box ... i.e., "/sw" is NOT in my path ... that said, the Python build 'insists' on building against: (1) the /System/... Tcl & Tk frameworks (2) libs/includes in /sw/... (e.g., ndbm.h ...) correcting the problem is INSENSITIVE to discreet inclusion of /Library/ Frameworks in LD_LIBRARY_PATH/DYLD_LIBRARY_PATH only the build time spec'n of: setenv LDFLAGS "-L/Library/Frameworks -framework Tcl -framework Tk" seems to do the trick ... as for /sw, only a: mv /sw /swTMP ( ... build ...) mv /swTMP /sw seems to work. cheers, richard ---------------------------------------------------------------------- >Comment By: blakers (blakers) Date: 2005-07-13 10:56 Message: Logged In: YES user_id=564069 1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1. AND, apparently, i still have a problem ... the WRONG HEADERS. even with: setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/ Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/ Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/ Tk.framework/Versions/Current/PrivateHeaders" set prior to configure, the build 'make' STILL complains abt: building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno- long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/ System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders - I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/ Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/ include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/ Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/ Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl - framework Tk In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h: 96, from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67: /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because linking not done gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno- long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/ System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders - I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/ Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/ include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/ Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/ Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl - framework Tk In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h: 96, from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17: /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because linking not done gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./ Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/ lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework Tk running build_scripts creating build/scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/ scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/ scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4 changing mode of build/scripts-2.4/pydoc from 644 to 755 changing mode of build/scripts-2.4/idle from 644 to 755 changing mode of build/scripts-2.4/smtpd.py from 644 to 755 cheers, richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237697&group_id=5470 From noreply at sourceforge.net Wed Jul 13 20:32:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 11:32:04 -0700 Subject: [ python-Bugs-1237697 ] link path probs on OSX re: Tcl, Tk & fink's /sw Message-ID: Bugs item #1237697, was opened at 2005-07-13 10:06 Message generated for change (Comment added) made by blakers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237697&group_id=5470 Please note that this 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: 7 Submitted By: blakers (blakers) Assigned to: Nobody/Anonymous (nobody) Summary: link path probs on OSX re: Tcl, Tk & fink's /sw Initial Comment: hi all, i'm bldg Python 2.4.1 on OSX 10.4.1 ... i've installed a late version of Tcl/Tk framework in: /Library/Frameworks/Tcl.framework /Library/Frameworks/Tk.framework iiuc, these frameworks/libs are SUPPOSED to be searched PRIOR to / System/Library/Frameworks ... i've installed the Fink dev env in "/sw" the Fink ev is 'disabled' o my box ... i.e., "/sw" is NOT in my path ... that said, the Python build 'insists' on building against: (1) the /System/... Tcl & Tk frameworks (2) libs/includes in /sw/... (e.g., ndbm.h ...) correcting the problem is INSENSITIVE to discreet inclusion of /Library/ Frameworks in LD_LIBRARY_PATH/DYLD_LIBRARY_PATH only the build time spec'n of: setenv LDFLAGS "-L/Library/Frameworks -framework Tcl -framework Tk" seems to do the trick ... as for /sw, only a: mv /sw /swTMP ( ... build ...) mv /swTMP /sw seems to work. cheers, richard ---------------------------------------------------------------------- >Comment By: blakers (blakers) Date: 2005-07-13 11:32 Message: Logged In: YES user_id=564069 1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1. AND, apparently, i still have a problem ... the WRONG HEADERS. even with: setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/ Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/ Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/ Tk.framework/Versions/Current/PrivateHeaders" set prior to configure, the build 'make' STILL complains abt: building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno- long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/ System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders - I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/ Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/ include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/ Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/ Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl - framework Tk In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h: 96, from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67: /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because linking not done gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno- long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/ System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders - I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/ Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/ include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/ Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/ Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl - framework Tk In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h: 96, from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17: /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because linking not done gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./ Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/ lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework Tk running build_scripts creating build/scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/ scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/ scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4 changing mode of build/scripts-2.4/pydoc from 644 to 755 changing mode of build/scripts-2.4/idle from 644 to 755 changing mode of build/scripts-2.4/smtpd.py from 644 to 755 cheers, richard ---------------------------------------------------------------------- Comment By: blakers (blakers) Date: 2005-07-13 10:56 Message: Logged In: YES user_id=564069 1st, i "lied" earlier ... i'm building on OSX 10.4.2, not 10.4.1. AND, apparently, i still have a problem ... the WRONG HEADERS. even with: setenv CPPFLAGS "-I/Library/Frameworks/Tcl.framework/Headers -I/ Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/ Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/ Tk.framework/Versions/Current/PrivateHeaders" set prior to configure, the build 'make' STILL complains abt: building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno- long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/ System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders - I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/ Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/ include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/ Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/ Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/_tkinter.c -o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o -framework Tcl - framework Tk In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h: 96, from /usr/ports/Python-2.4.1/Modules/_tkinter.c:67: /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because linking not done gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno- long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/ System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders - I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/ Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/ include -I. -I/usr/ports/Python-2.4.1/./Include -I/usr/ports/Python-2.4.1/./Mac/ Include -I/usr/local/include -I/usr/ports/Python-2.4.1/Include -I/usr/ports/ Python-2.4.1 -c /usr/ports/Python-2.4.1/Modules/tkappinit.c -o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -framework Tcl - framework Tk In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h: 96, from /usr/ports/Python-2.4.1/Modules/tkappinit.c:17: /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tcl: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.0: Tk: linker input file unused because linking not done gcc -L/Library/Frameworks -framework Tcl -framework Tk -bundle -undefined dynamic_lookup -L/Library/Frameworks -framework Tcl -framework Tk -I. -I./ Include build/temp.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.o build/ temp.darwin-8.2.0-Power_Macintosh-2.4/tkappinit.o -L/usr/local/lib -o build/ lib.darwin-8.2.0-Power_Macintosh-2.4/_tkinter.so -framework Tcl -framework Tk running build_scripts creating build/scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/pydoc -> build/ scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Tools/scripts/idle -> build/ scripts-2.4 copying and adjusting /usr/ports/Python-2.4.1/Lib/smtpd.py -> build/scripts-2.4 changing mode of build/scripts-2.4/pydoc from 644 to 755 changing mode of build/scripts-2.4/idle from 644 to 755 changing mode of build/scripts-2.4/smtpd.py from 644 to 755 cheers, richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237697&group_id=5470 From noreply at sourceforge.net Wed Jul 13 23:45:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 14:45:06 -0700 Subject: [ python-Feature Requests-1237678 ] add a note to eval and exec to not use it when possible Message-ID: Feature Requests item #1237678, was opened at 2005-07-13 11:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237678&group_id=5470 Please note that this 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: Rejected Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: add a note to eval and exec to not use it when possible Initial Comment: The docs for eval and exec should have pointers how to avoid them, by e.g. using locals(), globals(), getattr, setattr etc. Many questions pop up on c.l.py which could be answered by this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 16:45 Message: Logged In: YES user_id=80475 This should not be in the docs. Both eval() and exec are legitmate parts of the language with valid use cases. Avoidance of eval() and exec is a comp.lang.python security cult. If you feel the need, write a FAQ entry and submit it to Andrew. The entry should be neautrally worded with an informative note on the security risks of blindly running untrusted code and will a short listing of faster or more secure approaches for common use cases. Also, mention the input() includes an implicit call to eval(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237678&group_id=5470 From noreply at sourceforge.net Wed Jul 13 23:53:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 14:53:47 -0700 Subject: [ python-Feature Requests-1237680 ] add dedent() string method Message-ID: Feature Requests item #1237680, was opened at 2005-07-13 11:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237680&group_id=5470 Please note that this message 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: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: add dedent() string method Initial Comment: textwrap.dedent() is very useful for in-code multi-line string literals. However, as it is "hidden" in a module it does not really fit in, people don't use it and instead propose new string literal syntax for "dedented". str.dedent with an efficient C implementation would solve this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 16:53 Message: Logged In: YES user_id=80475 -1 * Being a top level function in a module doesn't count as hidden. This is no more hidden than collections.deque, glob.glob, or re.sub. * The API requirements are looser in a textwrap context. For a string method, there would need to be a universally useful decision about how to handle mixed spaces and tabs and whether the first line of a triple-quoted string would be handled differently. Am not sure if universal newlines present any additional issues. * The world-view of the string module is character oriented, not line oriented. A dedent method() is not a perfect fit. * While the topic comes up every few years, in general, there is no user demand for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1237680&group_id=5470 From noreply at sourceforge.net Wed Jul 13 23:57:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 14:57:47 -0700 Subject: [ python-Feature Requests-1232073 ] Links to tutorials and howtos from references Message-ID: Feature Requests item #1232073, was opened at 2005-07-04 03:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1232073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Links to tutorials and howtos from references Initial Comment: I see many people on comp.lang.python who are frustrated by the existing documentation, which is written at an advanced level for total beginners. It might aid in discoverability of the tutorial and howtos if more "See also" links were placed in language and library reference pages. For example: could link to . This would probably reduce the number of basic re questions on c.l.p and tutor, and make it easier to learn the language and stdlib. I'll submit my own patches as I have time. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 16:57 Message: Logged In: YES user_id=80475 -1 The reference docs need to remain loosely coupled or decoupled from the how-tos and tutorial. Links in the other direction are okay (the beginner's guides and overviews may reference the detailed docs). If you're interested in submitting docs patches, it would be nice to get the how-to guides up-to-date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1232073&group_id=5470 From noreply at sourceforge.net Wed Jul 13 23:58:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 14:58:53 -0700 Subject: [ python-Feature Requests-1226256 ] Add Jason Orendorff's path module to stdlib Message-ID: Feature Requests item #1226256, was opened at 2005-06-23 08:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1226256&group_id=5470 Please note that this message 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: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add Jason Orendorff's path module to stdlib Initial Comment: Jason Orendorff has produced an excellent path module which has an OOP approach to path, directory, and file manipulation, as well as including some new convenience functions. In my opinion, it allows much more Pythonic path manipulation than the functions in os and os.path. It is quite stable and includes unit tests. I and many others have been using it for years. http://www.jorendorff.com/articles/python/path/ I am requesting that it be added to the stdlib. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 16:58 Message: Logged In: YES user_id=80475 Guido was clear that an RFE is insufficient. A PEP is required if this is to advance. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-07-04 03:25 Message: Logged In: YES user_id=987664 Significant discussion on python-dev in this thread: http://mail.python.org/pipermail/python-dev/2005-June/054438.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1226256&group_id=5470 From noreply at sourceforge.net Thu Jul 14 00:05:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 15:05:49 -0700 Subject: [ python-Feature Requests-1232073 ] Links to tutorials and howtos from references Message-ID: Feature Requests item #1232073, was opened at 2005-07-04 08:28 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1232073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Links to tutorials and howtos from references Initial Comment: I see many people on comp.lang.python who are frustrated by the existing documentation, which is written at an advanced level for total beginners. It might aid in discoverability of the tutorial and howtos if more "See also" links were placed in language and library reference pages. For example: could link to . This would probably reduce the number of basic re questions on c.l.p and tutor, and make it easier to learn the language and stdlib. I'll submit my own patches as I have time. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2005-07-13 22:05 Message: Logged In: YES user_id=987664 Why? There are already many links to external documents (including howtos) and even dead-tree books in the reference docs. Try Googling for . This would definitely be helpful for beginners, and I don't see what the harm is. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 21:57 Message: Logged In: YES user_id=80475 -1 The reference docs need to remain loosely coupled or decoupled from the how-tos and tutorial. Links in the other direction are okay (the beginner's guides and overviews may reference the detailed docs). If you're interested in submitting docs patches, it would be nice to get the how-to guides up-to-date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1232073&group_id=5470 From noreply at sourceforge.net Thu Jul 14 00:14:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 15:14:51 -0700 Subject: [ python-Feature Requests-1214675 ] module warnings lacks a remove filter function Message-ID: Feature Requests item #1214675, was opened at 2005-06-04 02:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 Please note that this message 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: Torsten Bronger (bronger) Assigned to: Nobody/Anonymous (nobody) Summary: module warnings lacks a remove filter function Initial Comment: In the module warnings, there is no function for removing certain items from the list of warnings filters. The only options are to empty the list completely or to manipulate the warnings.filters list directly, both of which is unfortunate in my opinion. I attached a file with a removefilter() function. I don't know how safe it is to complete regular expressions, however, it works nicely for me. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 17:14 Message: Logged In: YES user_id=80475 Whether or not the use case is common is irrelevant if the solution is laced with problems (we don't add "works most of the time" functions). Am rejecting the removefilter() proposal. It doesn't scale-up for complex programs with multiple modules each using their own warning filters. It is too easy for innocuous looking code to violate another module's invariants. This is doubly true in a multi-threaded environment. +1 on the proposal for a Py2.5 context manager solution. That proposal is workable because the CM can specifically id() the filter that it added and later remove that exact entry if still present -- this will work even other modules have loaded an equivalent filter. To work in a threaded environement, the removal sequence should use a lock. ---------------------------------------------------------------------- Comment By: Chris Connett (cconnett) Date: 2005-07-08 13:53 Message: Logged In: YES user_id=1140166 ISTM the most common use case for this would be to set up some filter, perform some operation, then remove the filter. In this case, the removal wouldn't be far from the insertion, so it might not be unreasonable to keep around a reference to the added filter and remove it by identity when it's no longer needed ... if such a reference were available that is! As it stands, one does not get back a reference to the filter tuple added by filterwarnings(), so the only options left are to immediately grab warnings.filters[0], or construct one's own filter tuple manually (yech!). Some way should be provided to work in this case at least. As an aside, with 2.5's proposed context managers, a filter context could be added to this module so that a filter could be added and removed around the operation with a 'with' block. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-26 23:22 Message: Logged In: YES user_id=80475 I'm concerned that removefilter() may not work well in the presence of multiple modules that use the warnings module. It may be difficult to make sure the one removed wasn't subsequently added another module. Also, the issue is compounded because the order of filter application is important. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-04 07:48 Message: Logged In: YES user_id=6656 Pfft, this isn't Java! I'm not sure it should be done with impunity, but as a documented interface it makes perfect sense to me. ---------------------------------------------------------------------- Comment By: Torsten Bronger (bronger) Date: 2005-06-04 05:35 Message: Logged In: YES user_id=442234 It's simpler of course. However, if it's relatively easy to avoid, a module user should not manipulate module data structures directly, I think. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 04:33 Message: Logged In: YES user_id=1188172 I don't know, but wouldn't it be simpler to just document the warnings.filters attribute so that people know how to manipulate the list of filters? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1214675&group_id=5470 From noreply at sourceforge.net Thu Jul 14 00:24:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 15:24:47 -0700 Subject: [ python-Feature Requests-1216944 ] Add Error Code Dictionary to urllib2 Message-ID: Feature Requests item #1216944, was opened at 2005-06-08 04:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470 Please note that this message 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: Accepted Priority: 5 Submitted By: Mike Foord (mjfoord) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Add Error Code Dictionary to urllib2 Initial Comment: In order to properly handle 'HTTPError's from urllib2.urlopen you need to map error codes to an error message. I suggest the addition of the following dictionary to do that : # Table mapping response codes to messages; entries have the # form {code: (shortmessage, longmessage)}. httpresponses = { 100: ('Continue', 'Request received, please continue'), 101: ('Switching Protocols', 'Switching to new protocol; obey Upgrade header'), 200: ('OK', 'Request fulfilled, document follows'), 201: ('Created', 'Document created, URL follows'), 202: ('Accepted', 'Request accepted, processing continues off- line'), 203: ('Non-Authoritative Information', 'Request fulfilled from cache'), 204: ('No response', 'Request fulfilled, nothing follows'), 205: ('Reset Content', 'Clear input form for further input.'), 206: ('Partial Content', 'Partial content follows.'), 300: ('Multiple Choices', 'Object has several resources -- see URI list'), 301: ('Moved Permanently', 'Object moved permanently -- see URI list'), 302: ('Found', 'Object moved temporarily -- see URI list'), 303: ('See Other', 'Object moved -- see Method and URL list'), 304: ('Not modified', 'Document has not changed since given time'), 305: ('Use Proxy', 'You must use proxy specified in Location to access this ' 'resource.'), 307: ('Temporary Redirect', 'Object moved temporarily -- see URI list'), 400: ('Bad request', 'Bad request syntax or unsupported method'), 401: ('Unauthorized', 'No permission -- see authorization schemes'), 402: ('Payment required', 'No payment -- see charging schemes'), 403: ('Forbidden', 'Request forbidden -- authorization will not help'), 404: ('Not Found', 'Nothing matches the given URI'), 405: ('Method Not Allowed', 'Specified method is invalid for this server.'), 406: ('Not Acceptable', 'URI not available in preferred format.'), 407: ('Proxy Authentication Required', 'You must authenticate with ' 'this proxy before proceeding.'), 408: ('Request Time-out', 'Request timed out; try again later.'), 409: ('Conflict', 'Request conflict.'), 410: ('Gone', 'URI no longer exists and has been permanently removed.'), 411: ('Length Required', 'Client must specify Content-Length.'), 412: ('Precondition Failed', 'Precondition in headers is false.'), 413: ('Request Entity Too Large', 'Entity is too large.'), 414: ('Request-URI Too Long', 'URI is too long.'), 415: ('Unsupported Media Type', 'Entity body in unsupported format.'), 416: ('Requested Range Not Satisfiable', 'Cannot satisfy request range.'), 417: ('Expectation Failed', 'Expect condition could not be satisfied.'), 500: ('Internal error', 'Server got itself in trouble'), 501: ('Not Implemented', 'Server does not support this operation'), 502: ('Bad Gateway', 'Invalid responses from another server/proxy.'), 503: ('Service temporarily overloaded', 'The server cannot process the request due to a high load'), 504: ('Gateway timeout', 'The gateway server did not receive a timely response'), 505: ('HTTP Version not supported', 'Cannot fulfill request.'), } ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 17:24 Message: Logged In: YES user_id=80475 Reinfeld, you are welcome to put this in. Pay attention to the little details. Look-up the http protocol spec and use the exact spelling and exact upper/lower letter case. Only include the second field of the tuple if it is standard. I quickly looked at a couple of different sources and found that the "meaning" field was worded diffferently. If there is not a standard word-for-word official definition, then leave that part out and just have a simple mapping: {500: "Internal Error", 501: "Not Implemented, ...}. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-08 11:38 Message: Logged In: YES user_id=1188172 +1. This would simplify delivering messages to users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470 From noreply at sourceforge.net Thu Jul 14 02:35:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 17:35:25 -0700 Subject: [ python-Feature Requests-1232073 ] Links to tutorials and howtos from references Message-ID: Feature Requests item #1232073, was opened at 2005-07-04 03:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1232073&group_id=5470 Please note that this 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: Rejected Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Links to tutorials and howtos from references Initial Comment: I see many people on comp.lang.python who are frustrated by the existing documentation, which is written at an advanced level for total beginners. It might aid in discoverability of the tutorial and howtos if more "See also" links were placed in language and library reference pages. For example: could link to . This would probably reduce the number of basic re questions on c.l.p and tutor, and make it easier to learn the language and stdlib. I'll submit my own patches as I have time. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 19:35 Message: Logged In: YES user_id=80475 Sorry, I do not think this is a correct solution. Garbaging-up the authoritative references with more links does not make regexps any less challenging. Both the how-tos and tutorial are top level entries in the docs. They are not hidden. Also, users can turn to many other places besides the how-tos and tutorials which are not comprehensive and not unique -- there are tons of beginner guides (on-line and off). There is no doubt that the docs could be improved, but other appoaches need to be taken. There is no straight-forward transformation of what we have now into a guide that can teach people all about programming and how best to use the available tools. For better or worse, that task has been left to third-party guides (Dive into Python, Python & XML, Python in a Nutshell, Python and TkInter, etc). Nothing we can do can easily substitute for any of those. The docs cannot and should not purport to do otherwise. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-07-13 17:05 Message: Logged In: YES user_id=987664 Why? There are already many links to external documents (including howtos) and even dead-tree books in the reference docs. Try Googling for . This would definitely be helpful for beginners, and I don't see what the harm is. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-13 16:57 Message: Logged In: YES user_id=80475 -1 The reference docs need to remain loosely coupled or decoupled from the how-tos and tutorial. Links in the other direction are okay (the beginner's guides and overviews may reference the detailed docs). If you're interested in submitting docs patches, it would be nice to get the how-to guides up-to-date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1232073&group_id=5470 From noreply at sourceforge.net Thu Jul 14 08:41:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jul 2005 23:41:29 -0700 Subject: [ python-Feature Requests-1216944 ] Add Error Code Dictionary to urllib2 Message-ID: Feature Requests item #1216944, was opened at 2005-06-08 11:45 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470 Please note that this message 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: Accepted Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Add Error Code Dictionary to urllib2 Initial Comment: In order to properly handle 'HTTPError's from urllib2.urlopen you need to map error codes to an error message. I suggest the addition of the following dictionary to do that : # Table mapping response codes to messages; entries have the # form {code: (shortmessage, longmessage)}. httpresponses = { 100: ('Continue', 'Request received, please continue'), 101: ('Switching Protocols', 'Switching to new protocol; obey Upgrade header'), 200: ('OK', 'Request fulfilled, document follows'), 201: ('Created', 'Document created, URL follows'), 202: ('Accepted', 'Request accepted, processing continues off- line'), 203: ('Non-Authoritative Information', 'Request fulfilled from cache'), 204: ('No response', 'Request fulfilled, nothing follows'), 205: ('Reset Content', 'Clear input form for further input.'), 206: ('Partial Content', 'Partial content follows.'), 300: ('Multiple Choices', 'Object has several resources -- see URI list'), 301: ('Moved Permanently', 'Object moved permanently -- see URI list'), 302: ('Found', 'Object moved temporarily -- see URI list'), 303: ('See Other', 'Object moved -- see Method and URL list'), 304: ('Not modified', 'Document has not changed since given time'), 305: ('Use Proxy', 'You must use proxy specified in Location to access this ' 'resource.'), 307: ('Temporary Redirect', 'Object moved temporarily -- see URI list'), 400: ('Bad request', 'Bad request syntax or unsupported method'), 401: ('Unauthorized', 'No permission -- see authorization schemes'), 402: ('Payment required', 'No payment -- see charging schemes'), 403: ('Forbidden', 'Request forbidden -- authorization will not help'), 404: ('Not Found', 'Nothing matches the given URI'), 405: ('Method Not Allowed', 'Specified method is invalid for this server.'), 406: ('Not Acceptable', 'URI not available in preferred format.'), 407: ('Proxy Authentication Required', 'You must authenticate with ' 'this proxy before proceeding.'), 408: ('Request Time-out', 'Request timed out; try again later.'), 409: ('Conflict', 'Request conflict.'), 410: ('Gone', 'URI no longer exists and has been permanently removed.'), 411: ('Length Required', 'Client must specify Content-Length.'), 412: ('Precondition Failed', 'Precondition in headers is false.'), 413: ('Request Entity Too Large', 'Entity is too large.'), 414: ('Request-URI Too Long', 'URI is too long.'), 415: ('Unsupported Media Type', 'Entity body in unsupported format.'), 416: ('Requested Range Not Satisfiable', 'Cannot satisfy request range.'), 417: ('Expectation Failed', 'Expect condition could not be satisfied.'), 500: ('Internal error', 'Server got itself in trouble'), 501: ('Not Implemented', 'Server does not support this operation'), 502: ('Bad Gateway', 'Invalid responses from another server/proxy.'), 503: ('Service temporarily overloaded', 'The server cannot process the request due to a high load'), 504: ('Gateway timeout', 'The gateway server did not receive a timely response'), 505: ('HTTP Version not supported', 'Cannot fulfill request.'), } ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 08:41 Message: Logged In: YES user_id=1188172 Okay. Checked in (without the second field) as * Lib/urllib2.py r1.83 * Lib/test/test_urllib2.py r1.20 * Doc/lib/liburllib2.tex r1.23 * Misc/NEWS r1.1314 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-14 00:24 Message: Logged In: YES user_id=80475 Reinfeld, you are welcome to put this in. Pay attention to the little details. Look-up the http protocol spec and use the exact spelling and exact upper/lower letter case. Only include the second field of the tuple if it is standard. I quickly looked at a couple of different sources and found that the "meaning" field was worded diffferently. If there is not a standard word-for-word official definition, then leave that part out and just have a simple mapping: {500: "Internal Error", 501: "Not Implemented, ...}. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-08 18:38 Message: Logged In: YES user_id=1188172 +1. This would simplify delivering messages to users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&group_id=5470 From noreply at sourceforge.net Thu Jul 14 14:37:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 05:37:18 -0700 Subject: [ python-Bugs-1238170 ] threading.Thread uses {} as default argument Message-ID: Bugs item #1238170, was opened at 2005-07-14 15:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Thread uses {} as default argument Initial Comment: threading.Thread.__init__ uses {} as default argument for kwargs, shouldn't this be the usual def __init__(...,kwargs=None,...) ....if kwargs is None: ........kwargs = {} In normal cases, this is probably not a problem but it makes it possible to f*ck things up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&group_id=5470 From noreply at sourceforge.net Thu Jul 14 15:43:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 06:43:15 -0700 Subject: [ python-Bugs-1238210 ] manual.cls contains an invalid pdf-inquiry Message-ID: Bugs item #1238210, was opened at 2005-07-14 13: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=1238210&group_id=5470 Please note that this 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 Schindler (m-schindler) Assigned to: Nobody/Anonymous (nobody) Summary: manual.cls contains an invalid pdf-inquiry Initial Comment: I tried to compile the documentation for Python 2.4.1 (download today) but it fails with the message: pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. This is caused by the \pdfinfo call in manual.cls on line 72. I am using teTeX 3.0 where the LaTeX format is based on pdftex. Therefore, the inquiry for pdf, done in manual.cls with \@ifundefined{pdfinfo}{}{...} always returns true, for both pdf and dvi output. A better choice woud be using \ifpdf defined in python.sty Thanks, anyway for the great program! Michael Schindler ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 From noreply at sourceforge.net Thu Jul 14 15:45:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 06:45:38 -0700 Subject: [ python-Bugs-1238210 ] manual.cls contains an invalid pdf-inquiry Message-ID: Bugs item #1238210, was opened at 2005-07-14 13:43 Message generated for change (Settings changed) made by m-schindler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Schindler (m-schindler) Assigned to: Nobody/Anonymous (nobody) Summary: manual.cls contains an invalid pdf-inquiry Initial Comment: I tried to compile the documentation for Python 2.4.1 (download today) but it fails with the message: pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. This is caused by the \pdfinfo call in manual.cls on line 72. I am using teTeX 3.0 where the LaTeX format is based on pdftex. Therefore, the inquiry for pdf, done in manual.cls with \@ifundefined{pdfinfo}{}{...} always returns true, for both pdf and dvi output. A better choice woud be using \ifpdf defined in python.sty Thanks, anyway for the great program! Michael Schindler ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 From noreply at sourceforge.net Thu Jul 14 18:56:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 09:56:32 -0700 Subject: [ python-Bugs-1071094 ] some latex reject the pdfinfo macro while generating html Message-ID: Bugs item #1071094, was opened at 2004-11-22 17:15 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: Marc-Antoine Parent (maparent) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some latex reject the pdfinfo macro while generating html Initial Comment: I was building the documentation on OSX. I use the latest LaTeX 2004 from Wierda's teTeX. There is a pdfinfo command in Doc/ texinputs/manual.cls and Doc/texinputs/howto.cls which chokes my version of latex. edited log follows: TEXINPUTS=/.../Python-2.4c1/Doc/commontex: python /.../Python -2.4c1/Doc/tools/mkhowto --html --about html/stdabout.dat -- iconserver ../icons --favicon ../icons/pyfav.png --address "See About this document... for information on suggesting changes." --up-link ../index.html --up- title "Python Documentation Index" --global-module-index "../ modindex.html" --dvips-safe --dir html/api api/api.tex +++ TEXINPUTS=/.../Python-2.4c1/ Doc/api:/.../Python-2.4c1/Doc/ commontex:/.../Python-2.4c1/Doc/ paper-letter:/.../Python-2.4c1/Doc/ texinputs: +++ latex api *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. The relevant lines from the transcript are: ------------------------------------------------------------------------ +++ latex api This is pdfeTeX, Version 3.141592-1.20a-2.2 (Web2C 7.5.3) output format initialized to DVI entering extended mode (/.../Python-2.4c1/Doc/api/api.tex LaTeX2e <2003/12/01> Babel and hyphenation patterns for american, french, german, ngerman, nohyphenation, loaded. (/.../Python-2.4c1/Doc/texinputs/manual.cls Document Class: manual 1998/03/03 Document class (Python manual) (/.../Python-2.4c1/Doc/texinputs/pypaper.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/times.sty) Using Times instead of Computer Modern. ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/fancybox/ fancybox.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz) ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/report.cls Document Class: report 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/size10.clo)) (/.../Python-2.4c1/Doc/texinputs/fancyhdr.sty) Using fancier footers than usual. (/.../Python-2.4c1/Doc/texinputs/fncychap.sty) Using fancy chapter headings. (/.../Python-2.4c1/Doc/texinputs/python.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/longtable.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/verbatim.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/alltt.sty))) (/.../Python-2.4c1/Doc/commontex/boilerplate.tex (/.../Python-2.4c1/Doc/commontex/patchlevel.tex)) Writing index file api.idx No file api.aux. (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/ot1ptm.fd) pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. { \def \{, } \pdfinfo { /Author (\@author ) /Title (\@title ) } } l.12 \maketitle No pages of output. Transcript written on api.log. *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. make: *** [html/api/api.html] Error 1 ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 18:56 Message: Logged In: YES user_id=1188172 Duplicate of #1238210. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-07 22:33 Message: Logged In: YES user_id=1188172 FWIW, problem exists and patch works for me. Linux 2.6, teTeX 3.0. ---------------------------------------------------------------------- Comment By: S?bastien Maret (bmaret) Date: 2005-06-06 23:29 Message: Logged In: YES user_id=842097 The patch worked for me (MacOSX 10.4.1, teTeX 3.0). Thanks. ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-30 11:23 Message: Logged In: YES user_id=64920 This patch I got from a tex expert seems to fix it. It should also be applied to howto.cls. --- manual.cls.orig 2005-05-30 10:02:28.000000000 +0200 +++ manual.cls 2005-05-30 11:16:58.000000000 +0200 @@ -6,9 +6,17 @@ \ProvidesClass{manual} [1998/03/03 Document class (Python manual)] +\RequirePackage{ifpdf} +\newcommand*{\@ifpdftexisnotavailable}{% + \ifpdf + \expandafter\@secondoftwo + \else + \expandafter\@firstoftwo + \fi +} + \RequirePackage{pypaper} \RequirePackage{fancybox} - % Change the options here to get a different set of basic options, but only % if you have to. Paper and font size should be adjusted in pypaper.sty. % @@ -64,7 +72,7 @@ \let\footnotesize\small \let\footnoterule\relax \py at doHorizontalRule% - \@ifundefined{pdfinfo}{}{{ + \@ifpdftexisnotavailable{}{{ % This \def is required to deal with multi-line authors; it % changes \ to ', ' (comma-space), making it pass muster for % generating document info in the PDF file. ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-05-17 23:09 Message: Logged In: YES user_id=64920 I also have this problem when trying to build python-ldap's docs on SuSE Linux 9.3 which ships with tetex-3.0-13 and te_latex-3.0-13. You might wanna take note of this: http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=latex/3640&state=open It refers to this module: http://www.tex.ac.uk/tex-archive/macros/latex/contrib/oberdiek/ifpdf.sty ---------------------------------------------------------------------- Comment By: S?bastien Maret (bmaret) Date: 2005-04-18 21:53 Message: Logged In: YES user_id=842097 I get the exact same error. I am running MacOSX with teTeX 3.0 installed with Fink. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 From noreply at sourceforge.net Thu Jul 14 18:57:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 09:57:02 -0700 Subject: [ python-Bugs-1238210 ] manual.cls contains an invalid pdf-inquiry Message-ID: Bugs item #1238210, was opened at 2005-07-14 15:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Schindler (m-schindler) Assigned to: Nobody/Anonymous (nobody) Summary: manual.cls contains an invalid pdf-inquiry Initial Comment: I tried to compile the documentation for Python 2.4.1 (download today) but it fails with the message: pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. This is caused by the \pdfinfo call in manual.cls on line 72. I am using teTeX 3.0 where the LaTeX format is based on pdftex. Therefore, the inquiry for pdf, done in manual.cls with \@ifundefined{pdfinfo}{}{...} always returns true, for both pdf and dvi output. A better choice woud be using \ifpdf defined in python.sty Thanks, anyway for the great program! Michael Schindler ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 18:57 Message: Logged In: YES user_id=1188172 Seems to be also in howto.cls. Closed bug #1071094 as duplicate of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 From noreply at sourceforge.net Thu Jul 14 19:00:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 10:00:10 -0700 Subject: [ python-Bugs-1238210 ] manual.cls contains an invalid pdf-inquiry Message-ID: Bugs item #1238210, was opened at 2005-07-14 15:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Schindler (m-schindler) Assigned to: Nobody/Anonymous (nobody) Summary: manual.cls contains an invalid pdf-inquiry Initial Comment: I tried to compile the documentation for Python 2.4.1 (download today) but it fails with the message: pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. This is caused by the \pdfinfo call in manual.cls on line 72. I am using teTeX 3.0 where the LaTeX format is based on pdftex. Therefore, the inquiry for pdf, done in manual.cls with \@ifundefined{pdfinfo}{}{...} always returns true, for both pdf and dvi output. A better choice woud be using \ifpdf defined in python.sty Thanks, anyway for the great program! Michael Schindler ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 19:00 Message: Logged In: YES user_id=1188172 This is the fix from the old bug. --- manual.cls.orig 2005-05-30 10:02:28.000000000 +0200 +++ manual.cls 2005-05-30 11:16:58.000000000 +0200 @@ -6,9 +6,17 @@ \ProvidesClass{manual} [1998/03/03 Document class (Python manual)] +\RequirePackage{ifpdf} +\newcommand*{\@ifpdftexisnotavailable}{% + \ifpdf + \expandafter\@secondoftwo + \else + \expandafter\@firstoftwo + \fi +} + \RequirePackage{pypaper} \RequirePackage{fancybox} - % Change the options here to get a different set of basic options, but only % if you have to. Paper and font size should be adjusted in pypaper.sty. % @@ -64,7 +72,7 @@ \let\footnotesize\small \let\footnoterule\relax \py at doHorizontalRule% - \@ifundefined{pdfinfo}{}{{ + \@ifpdftexisnotavailable{}{{ % This \def is required to deal with multi-line authors; it % changes \ to ', ' (comma-space), making it pass muster for % generating document info in the PDF file. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 18:57 Message: Logged In: YES user_id=1188172 Seems to be also in howto.cls. Closed bug #1071094 as duplicate of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 From noreply at sourceforge.net Thu Jul 14 19:10:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 10:10:19 -0700 Subject: [ python-Bugs-1238210 ] manual.cls contains an invalid pdf-inquiry Message-ID: Bugs item #1238210, was opened at 2005-07-14 08:43 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Schindler (m-schindler) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: manual.cls contains an invalid pdf-inquiry Initial Comment: I tried to compile the documentation for Python 2.4.1 (download today) but it fails with the message: pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. This is caused by the \pdfinfo call in manual.cls on line 72. I am using teTeX 3.0 where the LaTeX format is based on pdftex. Therefore, the inquiry for pdf, done in manual.cls with \@ifundefined{pdfinfo}{}{...} always returns true, for both pdf and dvi output. A better choice woud be using \ifpdf defined in python.sty Thanks, anyway for the great program! Michael Schindler ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 12:00 Message: Logged In: YES user_id=1188172 This is the fix from the old bug. --- manual.cls.orig 2005-05-30 10:02:28.000000000 +0200 +++ manual.cls 2005-05-30 11:16:58.000000000 +0200 @@ -6,9 +6,17 @@ \ProvidesClass{manual} [1998/03/03 Document class (Python manual)] +\RequirePackage{ifpdf} +\newcommand*{\@ifpdftexisnotavailable}{% + \ifpdf + \expandafter\@secondoftwo + \else + \expandafter\@firstoftwo + \fi +} + \RequirePackage{pypaper} \RequirePackage{fancybox} - % Change the options here to get a different set of basic options, but only % if you have to. Paper and font size should be adjusted in pypaper.sty. % @@ -64,7 +72,7 @@ \let\footnotesize\small \let\footnoterule\relax \py at doHorizontalRule% - \@ifundefined{pdfinfo}{}{{ + \@ifpdftexisnotavailable{}{{ % This \def is required to deal with multi-line authors; it % changes \ to ', ' (comma-space), making it pass muster for % generating document info in the PDF file. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 11:57 Message: Logged In: YES user_id=1188172 Seems to be also in howto.cls. Closed bug #1071094 as duplicate of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 From noreply at sourceforge.net Fri Jul 15 04:25:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 19:25:21 -0700 Subject: [ python-Bugs-1234850 ] Admin privs required for Windows? Message-ID: Bugs item #1234850, was opened at 2005-07-08 11:52 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 Please note that this 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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-07-14 22:25 Message: Logged In: YES user_id=34881 Debbie Carraway in IT at NCSU gives this important analysis (she discovered this in the context of using the installer for VPython, which looks for Python 2.4 in HKLM\Software\Python\PythonCore\2.4\InstallPath; this used to work with Python 2.3): The problem is with the Python 2.4.1 installer. Python will put the InstallPath registry setting (which indicates where Python is installed) under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE under some circumstances: (1) if you are not a member of the Administrators group (2) if you choose "Install for Just Me" rather than "Install for All Users", (3) if you automate the Python install using "msiexec.exe /i python-2.4.1.msi /q". The /q (quiet) switch causes different behavior than the defaults with a manual install ("msiexec.exe /i python-2.4.1.msi"). This is a mistake in the Python installer. The path to an installed application always belongs under HKLM, because the path to installed software is a machine-specific setting. If the path is in HKCU, the InstallPath setting can follow a user to a machine where Python is not installed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 12:55 Message: Logged In: YES user_id=21627 The message comes from PC\bdist_wininst\install.c:OpenLogFile, when attempting to write to Software\Microsoft\CurrentVersion\Uninstall. Whether this goes to HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE apparently depends on whether Python was installed per-user or per-machine. In the 2.4.1 version, in CheckRootKey, there is a HasLocalMachinePrivs function. Mark Hammond added this in install.c 1.6 in response to #555812 and #555810, so I'm declaring this bug fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 14:59 Message: Logged In: YES user_id=31435 Bug 1232947 is about installing Python itself. This one is about installing a 3rd-party package that happens to use Python (a pre-existing Python), using a Windows installer created by Python's distutils package. It's unlikely the bugs have anything in common. ---------------------------------------------------------------------- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-07-08 14:48 Message: Logged In: YES user_id=1307917 Did you see bug # 1232947? It provides documentation of another failing non-admin install. (2.4.1). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 13:11 Message: Logged In: YES user_id=31435 You should be able to try 2.4. The Python installer includes msvcr71.dll, and should install it into the Python directory (instead of into a system directory) is you do a "install just for me" (as opposed to "all users") install. ---------------------------------------------------------------------- Comment By: Alex (hairypalm) Date: 2005-07-08 12:36 Message: Logged In: YES user_id=1309592 I am the original "complainant". I cannot try python 2.4 install package because it requires MSVCR71.dll. I am "locked down" at work and cannot write files except to my own user area. I am also prevented from writing to some areas of the registry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 From noreply at sourceforge.net Fri Jul 15 07:06:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 22:06:52 -0700 Subject: [ python-Bugs-1238681 ] freed pointer is used in longobject.c:long_pow() Message-ID: Bugs item #1238681, was opened at 2005-07-15 15: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=1238681&group_id=5470 Please note that this message 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: Luke (luked) Assigned to: Nobody/Anonymous (nobody) Summary: freed pointer is used in longobject.c:long_pow() Initial Comment: See in the following code snippet (from the end of the long_pow function in longobject.c) that "b" is used after it has been freed: Done: Py_XDECREF(a); Py_XDECREF(b); Py_XDECREF(c); Py_XDECREF(temp); if (b->ob_size > FIVEARY_CUTOFF) { for (i = 0; i < 32; ++i) Py_XDECREF(table[i]); } return (PyObject *)z; } The error exists in 2.4.1 and on CVS trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470 From noreply at sourceforge.net Fri Jul 15 07:26:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jul 2005 22:26:55 -0700 Subject: [ python-Bugs-1238681 ] freed pointer is used in longobject.c:long_pow() Message-ID: Bugs item #1238681, was opened at 2005-07-15 00:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470 Please note that this message 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: Luke (luked) >Assigned to: Tim Peters (tim_one) Summary: freed pointer is used in longobject.c:long_pow() Initial Comment: See in the following code snippet (from the end of the long_pow function in longobject.c) that "b" is used after it has been freed: Done: Py_XDECREF(a); Py_XDECREF(b); Py_XDECREF(c); Py_XDECREF(temp); if (b->ob_size > FIVEARY_CUTOFF) { for (i = 0; i < 32; ++i) Py_XDECREF(table[i]); } return (PyObject *)z; } The error exists in 2.4.1 and on CVS trunk. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-15 00:26 Message: Logged In: YES user_id=80475 Tim, I believe this one belongs to you (checkin 1.163 on 8/30/2004). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470 From noreply at sourceforge.net Fri Jul 15 10:31:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 01:31:54 -0700 Subject: [ python-Bugs-1238747 ] subprocess.Popen fails inside a Windows service Message-ID: Bugs item #1238747, was opened at 2005-07-15 09:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238747&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Adam Kerrison (adamk550) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen fails inside a Windows service Initial Comment: If you use subprocess.Popen() from within a Windows service and you try to redirect stdout or stderr, the call will fail with a TypeError. The issue appears to be that if you attempt to redirect stdout and/or stderr, the module also needs to set up stdin. Since you haven't specified what to do with stdin, the code simple duplicates the processes stdin handle using GetStdHandle(STD_INPUT_HANDLE) However, a Windows service doesn't have stdin etc so the returned handle is None. This handle is then passed to DuplicateHandle() which fails with the TypeError. A workaround is to explictly PIPE stdin but I have found at least one Windows program (the RCMD.EXE utility) that fails if its stdin is a pipe! (RCMD says "Internal Error 109" ...) The only other workaround is a to explictly open the NUL device and use that for stdin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238747&group_id=5470 From noreply at sourceforge.net Fri Jul 15 10:44:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 01:44:30 -0700 Subject: [ python-Bugs-1238747 ] subprocess.Popen fails inside a Windows service Message-ID: Bugs item #1238747, was opened at 2005-07-15 03:31 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238747&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Adam Kerrison (adamk550) >Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen fails inside a Windows service Initial Comment: If you use subprocess.Popen() from within a Windows service and you try to redirect stdout or stderr, the call will fail with a TypeError. The issue appears to be that if you attempt to redirect stdout and/or stderr, the module also needs to set up stdin. Since you haven't specified what to do with stdin, the code simple duplicates the processes stdin handle using GetStdHandle(STD_INPUT_HANDLE) However, a Windows service doesn't have stdin etc so the returned handle is None. This handle is then passed to DuplicateHandle() which fails with the TypeError. A workaround is to explictly PIPE stdin but I have found at least one Windows program (the RCMD.EXE utility) that fails if its stdin is a pipe! (RCMD says "Internal Error 109" ...) The only other workaround is a to explictly open the NUL device and use that for stdin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238747&group_id=5470 From noreply at sourceforge.net Fri Jul 15 10:57:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 01:57:24 -0700 Subject: [ python-Bugs-1238170 ] threading.Thread uses {} as default argument Message-ID: Bugs item #1238170, was opened at 2005-07-14 07:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: threading.Thread uses {} as default argument Initial Comment: threading.Thread.__init__ uses {} as default argument for kwargs, shouldn't this be the usual def __init__(...,kwargs=None,...) ....if kwargs is None: ........kwargs = {} In normal cases, this is probably not a problem but it makes it possible to f*ck things up. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-15 03:57 Message: Logged In: YES user_id=80475 This seems reasonable to me. Reinhold, would you like to do the honors (2.5 only)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&group_id=5470 From noreply at sourceforge.net Fri Jul 15 11:00:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 02:00:12 -0700 Subject: [ python-Bugs-1230484 ] tokenize bug Message-ID: Bugs item #1230484, was opened at 2005-06-30 12:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230484&group_id=5470 Please note that this message 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: Eduardo Aguiar (aguiar) >Assigned to: Tim Peters (tim_one) Summary: tokenize bug Initial Comment: hi, I have found a bug in 'tokenize' module: it is merging a COMMENT and a NL token for lines that start with a comment. I have made a fell changes and it seems to be working fine. Follows a patch: *** /usr/lib/python2.4/tokenize.py 2005-01-02 03:34:20.000000000 -0200 --- tokenize.py 2005-06-30 14:31:19.000000000 -0300 *************** *** 216,223 **** pos = pos + 1 if pos == max: break ! if line[pos] in '#\r\n': # skip comments or blank lines ! yield ((NL, COMMENT)[line[pos] == '#'], line[pos:], (lnum, pos), (lnum, len(line)), line) continue --- 216,235 ---- pos = pos + 1 if pos == max: break ! if line[pos] == '#': # skip comments ! end = len(line) - 1 ! while end > pos and line[end] in '\r\n': ! end = end - 1 ! end = end + 1 ! ! yield (COMMENT, line[pos:end], ! (lnum, pos), (lnum, end), line) ! yield (NL, line[end:], ! (lnum, end), (lnum, len(line)), line) ! continue ! ! if line[pos] in '\r\n': # skip blank lines ! yield (NL, line[pos:], (lnum, pos), (lnum, len(line)), line) continue Best regards, Eduardo Aguiar (eaguiar at programmer.net) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-15 04:00 Message: Logged In: YES user_id=80475 Tim, this affects a line you checked-in, 1.23 on 6/18/2001. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230484&group_id=5470 From noreply at sourceforge.net Fri Jul 15 11:13:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 02:13:29 -0700 Subject: [ python-Bugs-1238170 ] threading.Thread uses {} as default argument Message-ID: Bugs item #1238170, was opened at 2005-07-14 14:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: threading.Thread uses {} as default argument Initial Comment: threading.Thread.__init__ uses {} as default argument for kwargs, shouldn't this be the usual def __init__(...,kwargs=None,...) ....if kwargs is None: ........kwargs = {} In normal cases, this is probably not a problem but it makes it possible to f*ck things up. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-15 11:13 Message: Logged In: YES user_id=1188172 Committed as Lib/threading.py r1.49. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-15 10:57 Message: Logged In: YES user_id=80475 This seems reasonable to me. Reinhold, would you like to do the honors (2.5 only)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&group_id=5470 From noreply at sourceforge.net Fri Jul 15 17:22:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 08:22:07 -0700 Subject: [ python-Bugs-1234850 ] Admin privs required for Windows? Message-ID: Bugs item #1234850, was opened at 2005-07-08 17:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 Please note that this 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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-07-15 17:22 Message: Logged In: YES user_id=21627 bsherwood: How is your message related to this bug report? In this report, the OP reported a problem encountered with Python 2.3, whereas you seem to suggest a problem with Python 2.4; the OP indicated that the status of his problem is unknown for 2.4. If you want to report a bug in Python 2.4, please create a new bug report. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2005-07-15 04:25 Message: Logged In: YES user_id=34881 Debbie Carraway in IT at NCSU gives this important analysis (she discovered this in the context of using the installer for VPython, which looks for Python 2.4 in HKLM\Software\Python\PythonCore\2.4\InstallPath; this used to work with Python 2.3): The problem is with the Python 2.4.1 installer. Python will put the InstallPath registry setting (which indicates where Python is installed) under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE under some circumstances: (1) if you are not a member of the Administrators group (2) if you choose "Install for Just Me" rather than "Install for All Users", (3) if you automate the Python install using "msiexec.exe /i python-2.4.1.msi /q". The /q (quiet) switch causes different behavior than the defaults with a manual install ("msiexec.exe /i python-2.4.1.msi"). This is a mistake in the Python installer. The path to an installed application always belongs under HKLM, because the path to installed software is a machine-specific setting. If the path is in HKCU, the InstallPath setting can follow a user to a machine where Python is not installed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-11 18:55 Message: Logged In: YES user_id=21627 The message comes from PC\bdist_wininst\install.c:OpenLogFile, when attempting to write to Software\Microsoft\CurrentVersion\Uninstall. Whether this goes to HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE apparently depends on whether Python was installed per-user or per-machine. In the 2.4.1 version, in CheckRootKey, there is a HasLocalMachinePrivs function. Mark Hammond added this in install.c 1.6 in response to #555812 and #555810, so I'm declaring this bug fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 20:59 Message: Logged In: YES user_id=31435 Bug 1232947 is about installing Python itself. This one is about installing a 3rd-party package that happens to use Python (a pre-existing Python), using a Windows installer created by Python's distutils package. It's unlikely the bugs have anything in common. ---------------------------------------------------------------------- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-07-08 20:48 Message: Logged In: YES user_id=1307917 Did you see bug # 1232947? It provides documentation of another failing non-admin install. (2.4.1). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=31435 You should be able to try 2.4. The Python installer includes msvcr71.dll, and should install it into the Python directory (instead of into a system directory) is you do a "install just for me" (as opposed to "all users") install. ---------------------------------------------------------------------- Comment By: Alex (hairypalm) Date: 2005-07-08 18:36 Message: Logged In: YES user_id=1309592 I am the original "complainant". I cannot try python 2.4 install package because it requires MSVCR71.dll. I am "locked down" at work and cannot write files except to my own user area. I am also prevented from writing to some areas of the registry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 From noreply at sourceforge.net Fri Jul 15 18:57:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 09:57:40 -0700 Subject: [ python-Bugs-1233578 ] Pickle protocols 1, 2 can't handle "inf" floats. Message-ID: Bugs item #1233578, was opened at 2005-07-06 10:03 Message generated for change (Comment added) made by melicertes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233578&group_id=5470 Please note that this message 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: Charles (melicertes) Assigned to: Michael Hudson (mwh) Summary: Pickle protocols 1, 2 can't handle "inf" floats. Initial Comment: Python 2.4.1 on an AMD64 system. The pickle module barfs with a "SystemError: frexp() result out of range" if an "inf" float value is pickled with pickle protocol 1 or 2. It works fine with the old protocol 0. Minimal test case: >>> import pickle >>> o = 2e308 >>> print o inf >>> pickle.dumps(o, protocol=0) 'Finf\n.' >>> >>> pickle.dumps(o, protocol=1) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/usr/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range >>> >>> pickle.dumps(o, protocol=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/usr/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range ---------------------------------------------------------------------- >Comment By: Charles (melicertes) Date: 2005-07-15 10:57 Message: Logged In: YES user_id=1064824 > (And also the third time I've closed this bug in the last > fortnight! FFS guys!) FFS, indeed. Blame SourceForge's lousy search; I used the bug tracker search to look for all (open, closed, everything) reports for Python, all versions, keywords "pickle" and "inf" and got zero results. Similar searches on "pickle" and the exception name also produced zero results. Call me silly, but zero search results led me to believe that there /were/ no results. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-06 10:06 Message: Logged In: YES user_id=6656 This is fixed in CVS. (And also the third time I've closed this bug in the last fortnight! FFS guys!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233578&group_id=5470 From noreply at sourceforge.net Fri Jul 15 20:12:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 11:12:12 -0700 Subject: [ python-Bugs-1210326 ] comma separated cookie values Message-ID: Bugs item #1210326, was opened at 2005-05-28 11:13 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470 Please note that this message 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: tvogt (tovo) Assigned to: A.M. Kuchling (akuchling) Summary: comma separated cookie values Initial Comment: According to RFC 2109 "For backward compatibility, the separator in the Cookie header is semi-colon (;) everywhere. A server should also accept comma (,) as the separator between cookie-values for future compatibility." The Cookie standard module does not support this as it should. >>> import Cookie >>> c=Cookie.SimpleCookie() >>> c.load('foo=2, bar=3') >>> print c['foo'].value 2, ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-07-15 19:12 Message: Logged In: YES user_id=261020 I notice I didn't say explicitly: I think this should be closed, for the reasons given in my last two comments. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-06-29 20:53 Message: Logged In: YES user_id=261020 Forgot to add or demo in that CGI script: even Set-Cookie: abc=def, ghi=jkl is just one Netscape cookie, name 'abc', value 'def, ghi=jkl'. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-06-29 20:34 Message: Logged In: YES user_id=261020 Unfortunately one can't take the cookie specs at face value. Netscape cookies behaviour (the de-facto standard, ie. IE & Firefox behaviour -- cookie_spec.html is barely worth the web page it's written on, being flat-out wrong in several major ways, and very under-specified) has, I'm told, always simply been simply "split on semicolons". Certainly that's what IE and Mozilla do now: (this is just the text of a CGI for viewing: I didn't make it executable on reportlab.org) http://www.reportlab.org/~jjlee/cookie_demo.py IIRC RFC 2965 is only implemented by Opera, and is certainly now quite dead as an internet standard. (though I think it is useful as a guide for writing cookie-handling code, you can't follow blindly - not even close :-( ) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-02 00:19 Message: Logged In: YES user_id=11375 The updated cookie RFC, RFC 2965, also has this language. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210326&group_id=5470 From noreply at sourceforge.net Fri Jul 15 21:46:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 12:46:10 -0700 Subject: [ python-Bugs-1239120 ] Win registry problem Message-ID: Bugs item #1239120, was opened at 2005-07-15 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=1239120&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Win registry problem Initial Comment: Debbie Carraway in IT at NCSU gives this analysis of an apparent bug in the Python 2.4 installer for Windows. She discovered this in the context of using the installer for VPython, which looks for Python 2.4 in HKLM\Software\Python\PythonCore\2.4\InstallPath which used to work with Python 2.3. Here is her report: The problem is with the Python 2.4.1 installer. Python will put the InstallPath registry setting (which indicates where Python is installed) under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE under some circumstances: (1) if you are not a member of the Administrators group (2) if you choose "Install for Just Me" rather than "Install for All Users", (3) if you automate the Python install using "msiexec.exe /i python-2.4.1.msi /q". The /q (quiet) switch causes different behavior than the defaults with a manual install ("msiexec.exe /i python-2.4.1.msi"). This is a mistake in the Python installer. The path to an installed application always belongs under HKLM, because the path to installed software is a machine-specific setting. If the path is in HKCU, the InstallPath setting can follow a user to a machine where Python is not installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239120&group_id=5470 From noreply at sourceforge.net Fri Jul 15 23:01:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 14:01:20 -0700 Subject: [ python-Bugs-1239148 ] Win registry problem Message-ID: Bugs item #1239148, was opened at 2005-07-15 17:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Win registry problem Initial Comment: Debbie Carraway in IT at NCSU gives this analysis of an apparent bug in the Python 2.4 installer for Windows. She discovered this in the context of using the installer for VPython, which looks for Python 2.4 in HKLM\Software\Python\PythonCore\2.4\InstallPath which used to work with Python 2.3. Here is her report: The problem is with the Python 2.4.1 installer. Python will put the InstallPath registry setting (which indicates where Python is installed) under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE under some circumstances: (1) if you are not a member of the Administrators group (2) if you choose "Install for Just Me" rather than "Install for All Users", (3) if you automate the Python install using "msiexec.exe /i python-2.4.1.msi /q". The /q (quiet) switch causes different behavior than the defaults with a manual install ("msiexec.exe /i python-2.4.1.msi"). This is a mistake in the Python installer. The path to an installed application always belongs under HKLM, because the path to installed software is a machine-specific setting. If the path is in HKCU, the InstallPath setting can follow a user to a machine where Python is not installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239148&group_id=5470 From noreply at sourceforge.net Fri Jul 15 23:02:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 14:02:36 -0700 Subject: [ python-Bugs-1239148 ] Win registry problem Message-ID: Bugs item #1239148, was opened at 2005-07-15 17:01 Message generated for change (Settings changed) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Win registry problem Initial Comment: Debbie Carraway in IT at NCSU gives this analysis of an apparent bug in the Python 2.4 installer for Windows. She discovered this in the context of using the installer for VPython, which looks for Python 2.4 in HKLM\Software\Python\PythonCore\2.4\InstallPath which used to work with Python 2.3. Here is her report: The problem is with the Python 2.4.1 installer. Python will put the InstallPath registry setting (which indicates where Python is installed) under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE under some circumstances: (1) if you are not a member of the Administrators group (2) if you choose "Install for Just Me" rather than "Install for All Users", (3) if you automate the Python install using "msiexec.exe /i python-2.4.1.msi /q". The /q (quiet) switch causes different behavior than the defaults with a manual install ("msiexec.exe /i python-2.4.1.msi"). This is a mistake in the Python installer. The path to an installed application always belongs under HKLM, because the path to installed software is a machine-specific setting. If the path is in HKCU, the InstallPath setting can follow a user to a machine where Python is not installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239148&group_id=5470 From noreply at sourceforge.net Fri Jul 15 23:03:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 14:03:11 -0700 Subject: [ python-Bugs-1239148 ] Win registry problem Message-ID: Bugs item #1239148, was opened at 2005-07-15 17:01 Message generated for change (Settings changed) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 >Status: Deleted Resolution: Duplicate Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Win registry problem Initial Comment: Debbie Carraway in IT at NCSU gives this analysis of an apparent bug in the Python 2.4 installer for Windows. She discovered this in the context of using the installer for VPython, which looks for Python 2.4 in HKLM\Software\Python\PythonCore\2.4\InstallPath which used to work with Python 2.3. Here is her report: The problem is with the Python 2.4.1 installer. Python will put the InstallPath registry setting (which indicates where Python is installed) under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE under some circumstances: (1) if you are not a member of the Administrators group (2) if you choose "Install for Just Me" rather than "Install for All Users", (3) if you automate the Python install using "msiexec.exe /i python-2.4.1.msi /q". The /q (quiet) switch causes different behavior than the defaults with a manual install ("msiexec.exe /i python-2.4.1.msi"). This is a mistake in the Python installer. The path to an installed application always belongs under HKLM, because the path to installed software is a machine-specific setting. If the path is in HKCU, the InstallPath setting can follow a user to a machine where Python is not installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239148&group_id=5470 From noreply at sourceforge.net Sat Jul 16 00:00:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 15:00:27 -0700 Subject: [ python-Bugs-1239186 ] Install Error: "cannot compute sizeof (int), 77" Message-ID: Bugs item #1239186, was opened at 2005-07-15 18:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Gazzale (rgazzale) Assigned to: Nobody/Anonymous (nobody) Summary: Install Error: "cannot compute sizeof (int), 77" Initial Comment: Computer: Mac OS: Tiger 10.4.2 When attempting to install Python 2.4, I get the following error message in the "configure" stage: "checking size of int... configure: error: cannot compute sizeof (int), 77" config.log is attached. Many thanks, Bob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&group_id=5470 From noreply at sourceforge.net Sat Jul 16 00:23:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jul 2005 15:23:39 -0700 Subject: [ python-Bugs-1239186 ] Install Error: "cannot compute sizeof (int), 77" Message-ID: Bugs item #1239186, was opened at 2005-07-15 15:00 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Gazzale (rgazzale) Assigned to: Nobody/Anonymous (nobody) Summary: Install Error: "cannot compute sizeof (int), 77" Initial Comment: Computer: Mac OS: Tiger 10.4.2 When attempting to install Python 2.4, I get the following error message in the "configure" stage: "checking size of int... configure: error: cannot compute sizeof (int), 77" config.log is attached. Many thanks, Bob ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-15 15:23 Message: Logged In: YES user_id=357491 Are you using the standard version of gcc that comes with Tiger? I noticed in the log it says ``gcc (GCC) 4.1.0 20050517 (experimental)`` and I thought Tiger had gcc 4.0 (I can't check right now since I am at work), let alone came with a non-experimental version. Regardless, I don't see how it could be the configure files fault since Python does not have any control over the C compiler being able to determine the size of int. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&group_id=5470 From noreply at sourceforge.net Sun Jul 17 11:09:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 02:09:40 -0700 Subject: [ python-Bugs-1239681 ] email.Utils.formatdate documetaion missing Message-ID: Bugs item #1239681, was opened at 2005-07-17 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=1239681&group_id=5470 Please note that this 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: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: email.Utils.formatdate documetaion missing Initial Comment: email.Utils.formatdate documentation does not mention that 'usegmt' keyword argument is new on Python 2.4. reference: http://python.org/doc/2.4.1/lib/module-email.Utils.html http://python.org/doc/2.3.5/lib/module-email.Utils.html I don't know if its the rule, but usually the docs warn about new additions, and its very important when you try to create code that should work on multiple Python versions. Suggested fix replace: "Optional usegmt is a flag that when True, outputs a date string with the timezone as an ascii string GMT, rather than a numeric -0000. This is needed for some protocols (such as HTTP). This only applies when localtime is False" with: "Optional usegmt is a flag that when True, outputs a date string with the timezone as an ascii string GMT, rather than a numeric -0000. This is needed for some protocols (such as HTTP). This only applies when localtime is False. New in Python 2.4." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239681&group_id=5470 From noreply at sourceforge.net Sun Jul 17 13:50:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 04:50:43 -0700 Subject: [ python-Bugs-1239681 ] email.Utils.formatdate documetaion missing Message-ID: Bugs item #1239681, was opened at 2005-07-17 04:09 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239681&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Nir Soffer (nirs) >Assigned to: Skip Montanaro (montanaro) Summary: email.Utils.formatdate documetaion missing Initial Comment: email.Utils.formatdate documentation does not mention that 'usegmt' keyword argument is new on Python 2.4. reference: http://python.org/doc/2.4.1/lib/module-email.Utils.html http://python.org/doc/2.3.5/lib/module-email.Utils.html I don't know if its the rule, but usually the docs warn about new additions, and its very important when you try to create code that should work on multiple Python versions. Suggested fix replace: "Optional usegmt is a flag that when True, outputs a date string with the timezone as an ascii string GMT, rather than a numeric -0000. This is needed for some protocols (such as HTTP). This only applies when localtime is False" with: "Optional usegmt is a flag that when True, outputs a date string with the timezone as an ascii string GMT, rather than a numeric -0000. This is needed for some protocols (such as HTTP). This only applies when localtime is False. New in Python 2.4." ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-07-17 06:50 Message: Logged In: YES user_id=44345 Fixed in 2.4 and CVS docs. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239681&group_id=5470 From noreply at sourceforge.net Sun Jul 17 15:07:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 06:07:05 -0700 Subject: [ python-Feature Requests-414059 ] Floating point second in date/time tuple Message-ID: Feature Requests item #414059, was opened at 2001-04-05 19:33 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470 Please note that this message 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: 3 Submitted By: Tim Cera (timcera) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point second in date/time tuple Initial Comment: Would like to have this: >>> time.localtime(1057035600.6) (2003, 7, 1, 1, 0.6, 0, 1, 182, 1) Instead of: >>> time.localtime(1057035600.6) (2003, 7, 1, 1, 0, 0, 1, 182, 1) At a minimum the fractional seconds should be rounded instead of truncated. thanks tim cera ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-09 10:06 Message: Logged In: YES user_id=80475 Agree with Brett. Closing this one. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 00:55 Message: Logged In: YES user_id=357491 The problem is that the C library's localtime is used to do the conversion and that takes in a time_t argument. On almost all platforms this is a long int. Forcing the number to an integer prevent any unexpected warning about casting if the platform does support floats for some odd reason. The reason the argument is truncated is because the argument to PyArg_ParseTuple is 'd', which is integer. Python basically does what C would do which is truncate. You could round it up by taking the number as a Python object, calling Python's round function, and then extract the integer after the rounding. Trouble is that now your value accounts for time that you didn't even have. The plus side to truncating is your are not adding on time that did not occur; you are just losing some extra time you had. =). If you want to create a patch to rectify the situation you might get people to support the idea, but I don't view this as critical, especially when you can call round yourself before passing the value to localtime. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470 From noreply at sourceforge.net Sun Jul 17 15:11:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 06:11:28 -0700 Subject: [ python-Feature Requests-445484 ] pickle lacks float('inf') Message-ID: Feature Requests item #445484, was opened at 2001-07-28 17:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=445484&group_id=5470 Please note that this 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: 4 Submitted By: Anthony Doggett (anthonydoggett) Assigned to: Nobody/Anonymous (nobody) Summary: pickle lacks float('inf') Initial Comment: Support for float('inf') still appears to be missing in Python 2.1.1 (#1, Jul 28 2001, 14:15:01) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 >>> cPickle.dumps(float('inf'), 1) Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: frexp() result out of range >>> pickle.dumps(float('inf'), 1) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/var/ajd111/python/lib/python2.1/pickle.py", line 943, in dumps Pickler(file, bin).dump(object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 109, in dump self.save(object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 211, in save f(self, object) File "/var/ajd111/python/lib/python2.1/pickle.py", line 273, in save_float self.write(BINFLOAT + pack('>d', object)) SystemError: frexp() result out of range Both structmodule.c and cPickle.c require changes. Surely something like if (x == HUGE_VAL) { /* Inf */ e = 1024; f = 0.0; } else { f = frexp(x, &e); ... and if (e == 1024) x = HUGE_VAL; /* Inf */ else { is all that is required for all IEEE754 machines? (structmodule.c requires similar changes for Float also) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 15:11 Message: Logged In: YES user_id=1188172 This is in CVS for 2.5. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-13 03:12 Message: Logged In: YES user_id=31435 This appears to be outside the scope of PEP 754 (as defined by the PEP's author -- he's just aiming at symbolic constants and inquiry functions). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 02:46 Message: Logged In: YES user_id=357491 PEP 754 should make sure to deal with this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 22:16 Message: Logged In: YES user_id=31435 Changed to Feature Request, and added to new "Non- accidental 754 support" section of PEP 42. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 20:21 Message: Logged In: YES user_id=6380 Is there a point in keeping this bug report open indefinitely? A "won't fix" would make just as much sense. Maybe add Inf support to PEP 42. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-02 00:41 Message: Logged In: YES user_id=31435 Note that Python has no intentional support for Infs and NaNs anywhere; even that float('inf') doesn't blow up when you do it is a platform accident (it blows up ("invalid literal") on my box). Given that, in the absence of a comprehensive plan for supporting this stuff across the board, and worker bees to implement it, I downgraded the priority. A good plan would refactor the code so that dealing with the platform double and float formats occurs in only one place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=445484&group_id=5470 From noreply at sourceforge.net Sun Jul 17 15:15:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 06:15:56 -0700 Subject: [ python-Feature Requests-449227 ] rlcompleter add " (" to callables feature Message-ID: Feature Requests item #449227, was opened at 2001-08-08 20:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470 Please note that this 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: Roman Suzi (rnd0110) Assigned to: Nobody/Anonymous (nobody) Summary: rlcompleter add "(" to callables feature Initial Comment: I use rlcompleter extensively in interactive Python mode. I think it could be cool if callable objects were added "(" when completed. This way it will be much faster to program, without looking-up __doc__. For example: >>> f.fil<TAB> will give: >>> f.fileno(_ ("_" is to mark cursor position) and: >>> f.so<TAB> will (as before) give: >>> f.softspace _ ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 15:15 Message: Logged In: YES user_id=1188172 Any comments on this one? Sounds reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470 From noreply at sourceforge.net Sun Jul 17 15:48:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 06:48:18 -0700 Subject: [ python-Bugs-1239186 ] Install Error: "cannot compute sizeof (int), 77" Message-ID: Bugs item #1239186, was opened at 2005-07-15 18:00 Message generated for change (Comment added) made by rgazzale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Gazzale (rgazzale) Assigned to: Nobody/Anonymous (nobody) Summary: Install Error: "cannot compute sizeof (int), 77" Initial Comment: Computer: Mac OS: Tiger 10.4.2 When attempting to install Python 2.4, I get the following error message in the "configure" stage: "checking size of int... configure: error: cannot compute sizeof (int), 77" config.log is attached. Many thanks, Bob ---------------------------------------------------------------------- >Comment By: Bob Gazzale (rgazzale) Date: 2005-07-17 09:48 Message: Logged In: YES user_id=1313508 I am using the gcc I downloaded from Gaurav Khanna's HPC site. Thanks for the lead. I'll try going back to a non-experimental version of gcc. Bob ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-15 18:23 Message: Logged In: YES user_id=357491 Are you using the standard version of gcc that comes with Tiger? I noticed in the log it says ``gcc (GCC) 4.1.0 20050517 (experimental)`` and I thought Tiger had gcc 4.0 (I can't check right now since I am at work), let alone came with a non-experimental version. Regardless, I don't see how it could be the configure files fault since Python does not have any control over the C compiler being able to determine the size of int. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239186&group_id=5470 From noreply at sourceforge.net Sun Jul 17 15:49:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 06:49:10 -0700 Subject: [ python-Feature Requests-567972 ] Missing 4 socket object properties Message-ID: Feature Requests item #567972, was opened at 2002-06-12 13:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470 Please note that this message 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: Graham Horler (grahamh) >Assigned to: Martin v. L?wis (loewis) Summary: Missing 4 socket object properties Initial Comment: The C socketmodule has a struct PySocketSockObject, with family, type and proto members. These would be terribly helpful to have access to in Python, when implementing some generic socket helper functions. The "blocking" flag could also be made available, but would require some extra coding. (I'm using Python 2.1.3 under Linux 2.4.16, so I cannot extend the socket class itself ((as in py2.2)), and don't want to slow down sockets with a complete wrapper, as I use them heavily.) Thanks, Graham. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 15:49 Message: Logged In: YES user_id=1188172 Attaching a patch which implements the three members of _socket.socket. Please review. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-15 15:21 Message: Logged In: YES user_id=21627 Sounds good. Would you like to produce a patch implementing this feature? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 14:00 Message: Logged In: YES user_id=543663 Oh yes, the repr of a socket object includes the missing info, so to get hold of the family, I go: int(repr(sock).split(' ')[3].split('=')[1][:-1]) Similar for type and protocol, not nice! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470 From noreply at sourceforge.net Sun Jul 17 16:07:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 07:07:21 -0700 Subject: [ python-Feature Requests-739029 ] Constructor for counting things Message-ID: Feature Requests item #739029, was opened at 2003-05-17 04:22 Message generated for change (Comment added) made by birkenfeld 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: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 16: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 20: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 08: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 Sun Jul 17 16:12:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 07:12:30 -0700 Subject: [ python-Feature Requests-778763 ] Optional type enforcement Message-ID: Feature Requests item #778763, was opened at 2003-07-28 08:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778763&group_id=5470 Please note that this message 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: Postponed Priority: 5 Submitted By: Matt Perry (occupant4) Assigned to: Nobody/Anonymous (nobody) Summary: Optional type enforcement Initial Comment: One of the things that makes Python easy to code in is the fact that you don't have to explicitly declare the types of variables, or associate a specific type with a variable. However, this can potentially lead to somewhat confusing and hard-to-maintain code, not to mention make it easier to introduce bugs. An idea struck me that it might be possible to combine the power and safety of a strictly type-checked language with the speed and ease of coding of Python. Normal variables as they stand now would be unaffected by this feature, and retain their polymorphic type capabilities. Allow the programmer to optionally declare the type of a variable somehow, be it with the C-like syntax "int x", or Pascal's (I think?) "x: int", or a new syntactic representation. Python could then issue a TypeError if the program attempts to assign a non-int to x. Obviously this feature could apply to any data type, such as string, list, or perhaps user-defined classes. Class member variables can be declared as now in the class definition body, with the same syntax to specify a type, ie: class Test: int x = 5 string name = "test" untyped = None In addition, adding a type specifier to a function's parameters could serve another means of distinguishing it from other functions, which could allow function overloading, ie: def double(int x): return 2*x def double(string x): return x + ' ' + x Advantages: - clarifies the author's intention in writing code, and could help prevent confusion as to what type a variable/parameter is. - helps prevent bugs due to type mistakes - doesn't interfere with existing code or coding style, as dynamically typed variables are still allowed - could allow function overloading if it was wanted Disadvantages: - implementing a type checker could be difficult? - potentially pollutes namespace with extra keywords like 'string' or 'list'. may need to choose different keywords. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 16:12 Message: Logged In: YES user_id=1188172 This isn't going to be in Python 2.x, but presumably in Python 3k, so I'm closing it for now. (A change in 2.x would at least require a PEP) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-21 18:25 Message: Logged In: YES user_id=4771 This idea has always been considered but there are very deep issues with it. You should give a look to Pyrex, whose language a more static and type-checked version of Python. It produces C extension modules for the regular Python interpreter, so it can be mixed with regular Python code easily. google:python+pyrex ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-05 13:52 Message: Logged In: YES user_id=80475 To make the most of polymorphism, interface checking would be preferable to enforcing specific types. For example, it is better to check that f is a filelike type rather than requiring that is actually be a file -- that way, StringIO objects can be substituted without breaking code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778763&group_id=5470 From noreply at sourceforge.net Sun Jul 17 19:08:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 10:08:15 -0700 Subject: [ python-Feature Requests-567972 ] Missing 4 socket object properties Message-ID: Feature Requests item #567972, was opened at 2002-06-12 13:56 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470 Please note that this message 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: 7 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L?wis (loewis) Summary: Missing 4 socket object properties Initial Comment: The C socketmodule has a struct PySocketSockObject, with family, type and proto members. These would be terribly helpful to have access to in Python, when implementing some generic socket helper functions. The "blocking" flag could also be made available, but would require some extra coding. (I'm using Python 2.1.3 under Linux 2.4.16, so I cannot extend the socket class itself ((as in py2.2)), and don't want to slow down sockets with a complete wrapper, as I use them heavily.) Thanks, Graham. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 15:49 Message: Logged In: YES user_id=1188172 Attaching a patch which implements the three members of _socket.socket. Please review. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-15 15:21 Message: Logged In: YES user_id=21627 Sounds good. Would you like to produce a patch implementing this feature? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 14:00 Message: Logged In: YES user_id=543663 Oh yes, the repr of a socket object includes the missing info, so to get hold of the family, I go: int(repr(sock).split(' ')[3].split('=')[1][:-1]) Similar for type and protocol, not nice! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470 From noreply at sourceforge.net Sun Jul 17 21:56:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 12:56:52 -0700 Subject: [ python-Bugs-1223238 ] race in os.makedirs() Message-ID: Bugs item #1223238, was opened at 2005-06-18 18:37 Message generated for change (Comment added) made by birkenfeld 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: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 21:56 Message: Logged In: YES user_id=1188172 See patch #1239890. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-06-25 23: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 19: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 Sun Jul 17 22:05:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 13:05:59 -0700 Subject: [ python-Bugs-1061920 ] "k" specifier in PyArg_ParseTuple incomplete documentated Message-ID: Bugs item #1061920, was opened at 2004-11-07 15:28 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061920&group_id=5470 Please note that this 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: Gustavo J. A. M. Carneiro (gustavo) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "k" specifier in PyArg_ParseTuple incomplete documentated Initial Comment: Documentation for python 2.3 says: "k" (integer) [unsigned long] Convert a Python integer to a C unsigned long without overflow checking. New in version 2.3. However I was told -- and tested to be true -- that "k" also accepts python long as argument. This should be mentioned in the documentation, otherwise programmers will assume "k" only accepts values in the range 0-2^31, thus not allowing the full 'unsigned long' range. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:05 Message: Logged In: YES user_id=1188172 Fixed as Doc/api/utilities.tex r1.22, r1.20.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061920&group_id=5470 From noreply at sourceforge.net Sun Jul 17 22:27:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 13:27:53 -0700 Subject: [ python-Bugs-1015140 ] "article id" in description of NNTP objects Message-ID: Bugs item #1015140, was opened at 2004-08-24 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=1015140&group_id=5470 Please note that this 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: Felix Wiemann (felixwiemann) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "article id" in description of NNTP objects Initial Comment: lib/nntp-objects.html uses the term "article id" several times. This term is ambiguous though. Either "article number" or "message id" should be used. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:27 Message: Logged In: YES user_id=1188172 Corrected in docs and docstrings as Lib/nntplib.py r1.40, r1.39.2.1 Doc/lib/libnntplib.tex r1.33, r1.32.2.1 ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-08-30 22:13 Message: Logged In: YES user_id=1014490 > Patches are welcome. I don't have enough time (and I don't care enough) to write a patch for this, currently. > If you have a link to authoritive > guidance, that would be nice also. The only occurence of the case-insensitive regex 'article.id' in all RFCs is in RFC 977, which says: 223 n a article retrieved - request text separately (n = article number, a = unique article id) (Here, it probably means message-id.) There are frequent occurences of 'article number' and 'message-id' in the NNTP related RFCs 977 and 2980. So 'article id' probably should be avoided, as it is ambiguous. (The docs sometimes use it in the sense of 'message-id' and sometimes as 'article number', from what I could see.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-29 10:20 Message: Logged In: YES user_id=80475 Patches are welcome. If you have a link to authoritive guidance, that would be nice also. ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-08-29 10:11 Message: Logged In: YES user_id=1014490 Same problem for the docstrings in the source file Lib/nntplib.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 From noreply at sourceforge.net Sun Jul 17 22:31:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 13:31:50 -0700 Subject: [ python-Bugs-1014761 ] Missing urllib.urlretrieve docs Message-ID: Bugs item #1014761, was opened at 2004-08-24 00:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014761&group_id=5470 Please note that this 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: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Missing urllib.urlretrieve docs Initial Comment: urllib.urlretrieve docs give no description for the reporthook argument ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:31 Message: Logged In: YES user_id=1188172 Actually, they do, in the second paragraph of the urlretrieve docs. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014761&group_id=5470 From noreply at sourceforge.net Sun Jul 17 22:35:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 13:35:38 -0700 Subject: [ python-Bugs-1099363 ] refman doesn't know about universal newlines Message-ID: Bugs item #1099363, was opened at 2005-01-10 11:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099363&group_id=5470 Please note that this 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: refman doesn't know about universal newlines Initial Comment: The reference manual (in ref/ref2.tex) still talks about the various different end-of-line conventions, but as Python reads source code with universal newlines this is no longer relevant. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:35 Message: Logged In: YES user_id=1188172 This is already fixed since revision 1.57 of ref2.tex. Thanks for the report, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099363&group_id=5470 From noreply at sourceforge.net Sun Jul 17 23:01:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 14:01:05 -0700 Subject: [ python-Bugs-912943 ] 7.5.6 Thread Objects is too vague Message-ID: Bugs item #912943, was opened at 2004-03-09 20:16 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912943&group_id=5470 Please note that this 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: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: 7.5.6 Thread Objects is too vague Initial Comment: Some items which could be improved.... "Once the thread's activity is started, the thread is considered 'alive' and 'active' (these concepts are almost, but not quite exactly, the same; their definition is intentionally somewhat vague)." This is a bit silly. Either these attributes are intended to be exposed to users or they're not. If they are, they should be well defined. If not, they shouldn't be mentioned at all. "If the subclass overrides the constructor, it must make sure to invoke the base class constructor (Thread.__init__()) before doing anything else to the thread." This is misleading. You need to call "Thread.__init__ (self)", i.e. pass along the self argument. At least I think you do :-) "join([timeout]) ... When the timeout argument is present and not None, it should be a floating point number specifying a timeout for the operation in seconds (or fractions thereof)." What happens if you pass None? Does it wait forever? Is this any different from not passing any argument at all? What happens if a timeout occurs? Is there any way to differentiate between a timeout and a normal return? "A thread can be join()ed many times." Presumably only if all but the last call timed out? Or maybe not? If you get a normal return (i.e. not a timeout) from join(), and then call join() again, what happens? Does it just return immediately with no error? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:01 Message: Logged In: YES user_id=1188172 The second item is no bug. Methods in the docs are always written with a trailing "()". I have addressed the join() issues in Doc/lib/libthreading.tex r1.22, r1.20.4.2. Closing as the remaining issue is covered by the patch mentioned by alanvgreen. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-23 06:46 Message: Logged In: YES user_id=1174944 Submitted Patch 1107656 which addresses the 'alive' and 'active' issue. It does this by deprecating the isAlive() method and adding an isActive method instead. The patch also updates the documentation to talk about threads being 'active' rather than 'alive and active'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912943&group_id=5470 From noreply at sourceforge.net Sun Jul 17 23:10:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 14:10:20 -0700 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-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 Sun Jul 17 23:10:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 14:10:30 -0700 Subject: [ python-Bugs-872769 ] os.access() documentation should stress race conditions Message-ID: Bugs item #872769, was opened at 2004-01-08 02:40 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872769&group_id=5470 Please note that this 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: seth arnold (setharnold) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os.access() documentation should stress race conditions Initial Comment: Every version of the documentation I've seen associated with the os.access() function neglects to mention that its use is almost always a security vulnerability. For the versions of python that are still maintained, I'd like to see the documentation for this function expanded to include a paragraph very similar to the warning given in my system's access(2) manpage: Using access to check if a user is authorized to e.g., open a file before actually doing so using open(2) creates a security hole, because the user might exploit the short time interval between checking and opening the file to manipulate it. (This paragraph comes from a Debian system; if it is more work to validate the license on this manpage for including this paragraph here, I'd be happy to write some new content under whatever license is required to get a warning included.) Of course, there are web-based documents derived from the module's built-in documentation. It'd be keen if whoever fixes this in the module could poke the website document maintainer and ask them to regenerate the content. Thanks! ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:10 Message: Logged In: YES user_id=1188172 Thanks for the suggestion. Committed as Doc/lib/libos.tex r1.163, r1.146.2.9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872769&group_id=5470 From noreply at sourceforge.net Sun Jul 17 23:20:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 14:20:06 -0700 Subject: [ python-Bugs-1021621 ] use first_name, not first, in code samples Message-ID: Bugs item #1021621, was opened at 2004-09-03 07:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 Please note that this 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: Fixed Priority: 1 Submitted By: Steve R. Hastings (steveha) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: use first_name, not first, in code samples Initial Comment: Low priority documentation request. I'm studying the documentation on how to write a C module. http://docs.python.org/ext/node22.html Please update the sample code in the documentation to use "first_name" rather than "first" and "last_name" rather than "last". When I first studied the code and saw "first" and "last" members in a structure, I thought those were for a linked list of some sort. Much later in the code I realized that the object was supposed to have a first name and a last name, and there was no linked list at all. "first_name" would be much more self-documenting than "first". An acceptable alternative would be a comment after the "first" declaration, saying: /* first name */ This is a small point, but I think it would be an improvement to the documentation. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:20 Message: Logged In: YES user_id=1188172 While mwh's new docs are in the making, I added the comments you suggested as Doc/ext/noddy2.c r1.5.4.1, r1.6. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-03 12:59 Message: Logged In: YES user_id=6656 FWIW, I agree. I'm attempting to rewrite the extending and embedding manual, and yes, this is one of the things I've changed. I've just uploaded my latest draft to http://starship.python.net/crew/mwh/toext/ which gets a little way into the area of defining new types. I'd really appreciate your comments! (to mwh at python.net, please). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 From noreply at sourceforge.net Sun Jul 17 23:44:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 14:44:16 -0700 Subject: [ python-Bugs-1239948 ] distutils: MetroWerks support can go Message-ID: Bugs item #1239948, was opened at 2005-07-17 23:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Anthony Baxter (anthonybaxter) Summary: distutils: MetroWerks support can go Initial Comment: I'm not sure how far back the current distutils (i.e. the one from the CVS trunk) is supposed to be backward compatible, but from 2.4 onwards Python does not support Mac OS 9 anymore, and therefore support for the MetroWerks C compiler can be ripped out. Theoretically there's an MW compiler on windows too, but nobody uses it and the mwerkscompiler object in distutils currently only support the Mac compiler. And actually only that in the exact way that MacPython used it. I'm basically asking for an opinion here: is it a good idea to rip mwerkscompiler out. Feel free to assign back to me to do the work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239948&group_id=5470 From noreply at sourceforge.net Sun Jul 17 23:57:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 14:57:41 -0700 Subject: [ python-Bugs-1217591 ] make frameworkinstall fails for non-default location Message-ID: Bugs item #1217591, was opened at 2005-06-09 16:54 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217591&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Jack Jansen (jackjansen) Summary: make frameworkinstall fails for non-default location Initial Comment: Mac OS X 10.3.8, Python 2.4.1. Attempts to 'make frameworkinstall' to a non-default prefix and framework location fail: $ ./configure --prefix= --enable-framework=/Frameworks $ make $ make frameworkinstall The last step always attempts to create /usr/local/bin/python, instead of /bin/python. The immediate cause appears to be line 20 of Mac/OSX/Makefile: bindir=/usr/local/bin The problem is easier to spot if the 'make frameworkinstall' step is performed without root permissions: $ ./configure --prefix=${HOME}/tmp/py241 --enable- framework=${HOME}/tmp/py241/Frameworks ... $ make ... $ make frameworkinstall ... make -f ./Mac/OSX/Makefile installunixtools DIRMODE=755 FILEMODE=644 srcdir=. builddir=. DESTDIR= prefix=/Users/myself/tmp/py241/ Frameworks/Python.framework/Versions/2.4 /usr/bin/install -c -d /usr/local/bin install: chmod 755 /usr/local/bin: Operation not permitted ln -fsn /Users/myself/tmp/py241/Frameworks/Python.framework/ Versions/2.4/bin/python /usr/local/bin/python2.4 ln: /usr/local/bin/python2.4: Permission denied make[1]: *** [installunixtools] Error 1 make: *** [frameworkinstallunixtools] Error 2 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-07-17 23:57 Message: Logged In: YES user_id=45365 The bad news is that this is difficult to fix: the whole "frameworkinstall" sequence is a bit of a hack, and it works by overriding prefix to point into the bowels of the framework and then doing the equivalent of a "make install". The good news is that if I understand correctly what you're trying to do, building to a staging area so you can package things for distribution later, there's another way to do this that does work: use the DESTROOT environment variable. If you do "DESTROOT=/tmp/py241 configure -- enable-frameworks" you'll get a tree ready for installation in /tmp/py241. But that assumes you can live with /tmp/py241/usr/local/bin. If your needs are different reopen the bug and explain your use case and I'll think harder about a solution:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217591&group_id=5470 From noreply at sourceforge.net Mon Jul 18 01:47:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Jul 2005 16:47:19 -0700 Subject: [ python-Bugs-1238681 ] freed pointer is used in longobject.c:long_pow() Message-ID: Bugs item #1238681, was opened at 2005-07-15 01:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Luke (luked) Assigned to: Tim Peters (tim_one) Summary: freed pointer is used in longobject.c:long_pow() Initial Comment: See in the following code snippet (from the end of the long_pow function in longobject.c) that "b" is used after it has been freed: Done: Py_XDECREF(a); Py_XDECREF(b); Py_XDECREF(c); Py_XDECREF(temp); if (b->ob_size > FIVEARY_CUTOFF) { for (i = 0; i < 32; ++i) Py_XDECREF(table[i]); } return (PyObject *)z; } The error exists in 2.4.1 and on CVS trunk. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-17 19:47 Message: Logged In: YES user_id=31435 Eww -- gross. Thanks for the report! Repaired (along with a another long_pow() coding error) in: Misc/NEWS 1.1319 Objects/longobject.c 1.169 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-15 01:26 Message: Logged In: YES user_id=80475 Tim, I believe this one belongs to you (checkin 1.163 on 8/30/2004). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470 From noreply at sourceforge.net Mon Jul 18 09:24:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 00:24:51 -0700 Subject: [ python-Bugs-1238681 ] freed pointer is used in longobject.c:long_pow() Message-ID: Bugs item #1238681, was opened at 2005-07-15 07:06 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Luke (luked) Assigned to: Tim Peters (tim_one) Summary: freed pointer is used in longobject.c:long_pow() Initial Comment: See in the following code snippet (from the end of the long_pow function in longobject.c) that "b" is used after it has been freed: Done: Py_XDECREF(a); Py_XDECREF(b); Py_XDECREF(c); Py_XDECREF(temp); if (b->ob_size > FIVEARY_CUTOFF) { for (i = 0; i < 32; ++i) Py_XDECREF(table[i]); } return (PyObject *)z; } The error exists in 2.4.1 and on CVS trunk. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-18 09:24 Message: Logged In: YES user_id=1188172 And backported as Objects/longobject.c r1.165.2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-18 01:47 Message: Logged In: YES user_id=31435 Eww -- gross. Thanks for the report! Repaired (along with a another long_pow() coding error) in: Misc/NEWS 1.1319 Objects/longobject.c 1.169 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-15 07:26 Message: Logged In: YES user_id=80475 Tim, I believe this one belongs to you (checkin 1.163 on 8/30/2004). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470 From noreply at sourceforge.net Mon Jul 18 09:39:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 00:39:31 -0700 Subject: [ python-Bugs-957505 ] SocketServer module documentation misleading Message-ID: Bugs item #957505, was opened at 2004-05-20 18:42 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957505&group_id=5470 Please note that this 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: Jon Giddy (jongiddy) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: SocketServer module documentation misleading Initial Comment: The Python Library Reference page for the SocketServer module refers to RequestHandlerClass as though it was the name of an actual class. Actually, it should be either "request handler class" or "BaseRequestHandler". Secondly, in the second para of the BaseRequestHandler handle() method description, StreamRequestHandler and DatagramRequestHandler are referred to as mix-in classes when they are in fact subclasses of BaseRequestHandler. This error is also present in the comments at the start of the module. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-18 09:39 Message: Logged In: YES user_id=1188172 Thanks for the suggestions. Your first point has already been clarified by adding more explanation to the docs, the second point I have corrected in Doc/lib/libsocksvr.tex r1.20, r1.18.4.2, Lib/SocketServer.py r1.40, r1.37.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957505&group_id=5470 From noreply at sourceforge.net Mon Jul 18 10:05:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 01:05:14 -0700 Subject: [ python-Bugs-850238 ] unclear documentation/missing command? Message-ID: Bugs item #850238, was opened at 2003-11-27 14:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850238&group_id=5470 Please note that this 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: Andreas Kostyrka (yacc143) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: unclear documentation/missing command? Initial Comment: Hi! The documentation of \declaremodule (http://www.python.org/doc/2.3.2/doc/module-markup.html) misses one important thing: It only works as such if you use one \section per module. (I had some fun LaTeX debugging to find it) It should also be noted, that perhaps an extra command to call \py at reset, something like \endmodule, this way the author could specify which part of the file pertains to certain module. Alternativly, perhaps \declaremodule should flush out any module info that is already entered? Andreas ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-18 10:05 Message: Logged In: YES user_id=1188172 Added a remark that each module should be documented in its own \section. Doc/doc/doc.tex r1.94, 1.90.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850238&group_id=5470 From noreply at sourceforge.net Mon Jul 18 10:17:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 01:17:53 -0700 Subject: [ python-Bugs-755617 ] os module: Need a better description of " mode" Message-ID: Bugs item #755617, was opened at 2003-06-17 02:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470 Please note that this 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: Matthew Shomphe (mshomphe) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: os module: Need a better description of "mode" Initial Comment: The page <http://www.python. org/doc/current/lib/os-file-dir.html> says the following about the function os.chmod: chmod(path, mode) Change the mode of path to the numeric mode. Availability: Unix, Windows. The "mode" values are unclear. It turns out that the UNIX file permission set (e.g., 0666 for read/writeable) works with the Windows set (where 0666 translates to 33206). Is it possible to describe the file permissions in more detail in the documentation at this point? Attached is an email thread discussing this documentation issue. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-18 10:17 Message: Logged In: YES user_id=1188172 Added this note to the chmod docs: Although Windows supports chmod, you can only set the file's read-only flag with this function (via the \code{S_IWRITE} and \code{S_IREAD} constants or a corresponding integer value). All other bits are ignored. Doc/lib/libos.tex r1.164, r1.146.2.10. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-05 20:28 Message: Logged In: YES user_id=1188172 I think the wording suggested by logistix would be a good addition to the docs. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-06-17 21:31 Message: Logged In: YES user_id=699438 Something like: "NOTE: Although Windows supports chmod, it incorporates much different functionality than a typical Unix user would expect. Please refer to Microsoft?s documentation for more details." would be nice. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-17 17:18 Message: Logged In: YES user_id=531881 Tim- I captured what Matthew Shomphe recommended into patch 755677 (http://www.python.org/sf/755677). Hope this helps. -c ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-17 16:49 Message: Logged In: YES user_id=31435 Then please suggest the actual text you want to see in the docs. I can't do it for you (for example, chmod has always done exactly what I've wanted it to do on Windows -- but then I've never wanted to do anything with it on Windows beyond fiddling the readonly bit). ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-06-17 07:35 Message: Logged In: YES user_id=699438 All I'm saying is that although chmod is valid windows call, it will not produce the effect that most users expect. There's no harm in calling it, but it's not going to accomplish what most users want it to do. This information is more important to a user than other inconsistencies in the Windows implementation. (i.e. os.stat returning a value that is different than chmod set) ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-17 05:37 Message: Logged In: YES user_id=531881 see patch 755677 sheesh neal, you couldn't patch this? ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-17 05:28 Message: Logged In: YES user_id=31435 Well, let's not overreact here -- MS's _chmod simply calls the Win32 SetFileAttributes(), and the only thing it can change is the FILE_ATTRIBUTE_READONLY flag. That's all part of Windows base services, and makes sense on FAT too. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-06-17 04:51 Message: Logged In: YES user_id=699438 Realistically, you should NEVER intentionally use chmod to set file permissions on Windows. The FAT filesystem has no permissions, and NTFS has ACLs which are much too complex to map to a chmod style call. MS only has chmod support so they can claim some level of posix compliance. I'm not saying you should drop the ability to call os.chmod on windows, but perhaps the docs should say that its not the recommended way of doing things. Unfortunately, there's not a recommended way of setting security that'll work on all Windows platforms either (although I'd start with os.popen ("cacls ...") Even win32security requires some serious programming just to get started with manipulating ACLs. Typical security looks something like this: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\grant>xcacls "\Program files" C:\Program Files BUILTIN\Users:R BUILTIN\Users:(OI)(CI)(IO)(special access:) GENERIC_READ GENERIC_EXECUTE BUILTIN\Power Users:C BUILTIN\Power Users:(OI)(CI)(IO)C BUILTIN\Administrators:F BUILTIN\Administrators:(OI)(CI)(IO)F NT AUTHORITY\SYSTEM:F NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F BUILTIN\Administrators:F CREATOR OWNER:(OI)(CI)(IO)F C:\Documents and Settings\grant> ---------------------------------------------------------------------- Comment By: Matthew Shomphe (mshomphe) Date: 2003-06-17 04:05 Message: Logged In: YES user_id=716326 Here's my first pass at some additional documentation. My HTML skills are not up to par, but I've tried :) I've attached the document separately. m@ ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-17 03:06 Message: Logged In: YES user_id=33168 Could you try to produce a patch to improve the documentation? Or perhaps suggest better wording? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&group_id=5470 From noreply at sourceforge.net Mon Jul 18 12:57:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 03:57:46 -0700 Subject: [ python-Bugs-1231069 ] ioctl has problem with -ive request codes Message-ID: Bugs item #1231069, was opened at 2005-07-01 17:24 Message generated for change (Comment added) made by barry-scott You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 Please note that this 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: Barry Alan Scott (barry-scott) Assigned to: Michael Hudson (mwh) Summary: ioctl has problem with -ive request codes Initial Comment: On Linux many ioctl request code values cannot be passed to ioctl because it assumes that the values are signed ints. Value with the top bit set 0x8000000 are common. Changing the PyArg_ParseTuple calls to use "I" instead of "i" fixes the problem. This may well also be the issue with bug 1112949 "ioctl has problems on 64 bit machines". The attached patch fixes the problem in 2.4.1 and was tested on FC4. ---------------------------------------------------------------------- >Comment By: Barry Alan Scott (barry-scott) Date: 2005-07-18 11:57 Message: Logged In: YES user_id=28665 I've messed up attchments on SF before but the patch downloads for me. Barry ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-03 15:50 Message: Logged In: YES user_id=6656 The patch seems to be empty (!?) Good idea, although not goo enough for me to fight CVS over dialup... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 From noreply at sourceforge.net Mon Jul 18 14:08:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jul 2005 05:08:03 -0700 Subject: [ python-Bugs-1223238 ] race in os.makedirs() Message-ID: Bugs item #1223238, was opened at 2005-06-18 18:37 Message generated for change (Comment added) made by yorick 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: Mattias Engdeg?rd (yorick) Date: 2005-07-18 14: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-17 23: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 21:56 Message: Logged In: YES user_id=1188172 See patch #1239890. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-06-25 23: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 19: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 Tue Jul 19 18:05:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jul 2005 09:05:05 -0700 Subject: [ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files Message-ID: Bugs item #1200686, was opened at 2005-05-12 16:19 Message generated for change (Comment added) made by julien_sagnard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 Please note that this 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: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError raised on win32 for correct files Initial Comment: Try to import the attached file (dt.py) on Windows with Python 2.4 or 2.4.1 and you'll get a SyntaxError (the file was written a long time ago, and worked perfectly well on Python 2.1, 2.2 and 2.3.) The same does not happen when importing the same module on Linux (tested with 2.4 and 2.4.1). When the module imports fine you'll get an ImportError (don't want to attach all dependencies here) but the SyntaxError comes before that. Also note that compiling the file with compiler.compileFile("dt.py") generates a perfectly good .pyc file that can be later imported just fine (tested with 2.4 and 2.4.1 on Windows). ---------------------------------------------------------------------- Comment By: Julien Sagnard (julien_sagnard) Date: 2005-07-19 18:05 Message: Logged In: YES user_id=1181710 I have a similar problem with an other file (log.py). On my computer ( Windows 2000 ) this 2 files ( log.py and dt.py ) works with python 2.4 but raise a syntax error on python 2.4.1 : D:\dvt\tmp\bug2_4_1>python -c "import log" Traceback (most recent call last): File "", line 1, in ? File "D:\dvt\tmp\bug2_4_1\log.py", line 356 w = 72 ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-05-18 16:15 Message: Logged In: YES user_id=86307 I'm fairly sure this is caused by the bug described here: www.python.org/sf/1175396 The module imports without syntax error on my Windows system (with a patched codecs.py to work around the above bug). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 From noreply at sourceforge.net Tue Jul 19 18:19:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jul 2005 09:19:08 -0700 Subject: [ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files Message-ID: Bugs item #1200686, was opened at 2005-05-12 16:19 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 Please note that this 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: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError raised on win32 for correct files Initial Comment: Try to import the attached file (dt.py) on Windows with Python 2.4 or 2.4.1 and you'll get a SyntaxError (the file was written a long time ago, and worked perfectly well on Python 2.1, 2.2 and 2.3.) The same does not happen when importing the same module on Linux (tested with 2.4 and 2.4.1). When the module imports fine you'll get an ImportError (don't want to attach all dependencies here) but the SyntaxError comes before that. Also note that compiling the file with compiler.compileFile("dt.py") generates a perfectly good .pyc file that can be later imported just fine (tested with 2.4 and 2.4.1 on Windows). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-07-19 18:19 Message: Logged In: YES user_id=89016 This bug should be fixed in the current CVS version. So, can you retry with current CVS? As a workaround you might also want to remove the PEP 263 coding declaration if you don't have any special character in your file. ---------------------------------------------------------------------- Comment By: Julien Sagnard (julien_sagnard) Date: 2005-07-19 18:05 Message: Logged In: YES user_id=1181710 I have a similar problem with an other file (log.py). On my computer ( Windows 2000 ) this 2 files ( log.py and dt.py ) works with python 2.4 but raise a syntax error on python 2.4.1 : D:\dvt\tmp\bug2_4_1>python -c "import log" Traceback (most recent call last): File "", line 1, in ? File "D:\dvt\tmp\bug2_4_1\log.py", line 356 w = 72 ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-05-18 16:15 Message: Logged In: YES user_id=86307 I'm fairly sure this is caused by the bug described here: www.python.org/sf/1175396 The module imports without syntax error on my Windows system (with a patched codecs.py to work around the above bug). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 From noreply at sourceforge.net Tue Jul 19 18:22:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jul 2005 09:22:11 -0700 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 06:13 Message generated for change (Comment added) made by sjuranic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Please note that this 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: Maik Hertha (mhertha) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- Comment By: Steve Juranich (sjuranic) Date: 2005-07-19 10:22 Message: Logged In: YES user_id=1315245 FWIW, this same problem crops up when using Python & VTK together (which also ships with its own version of expat). bos's workaround will make things work, though. ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2005-03-29 11:11 Message: Logged In: YES user_id=2369 I ran into this problem as well on a debian GNU/Linux system on x86 hardware. It occurs both with pygtk 2.4 and wxPython 2.5 both built against gtk 2.4. bos' patch at least solves the immediate problem of the segmentation fault. It may be a good idea to print a warning message if some of the error codes cannot be translated to strings, though. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-04 16:16 Message: Logged In: YES user_id=28380 With the GNU linker, you can pass in -Bstatic to force it to resolve the symbols in the local shared library, instead of globally. This also works on Irix. I don't know about other Unixes. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-02 03:35 Message: Logged In: YES user_id=6656 It's a nasty one, I'll give you that. Fred, what do you think of bos's patch? It solves the immediate issue, but I'm not sure it's a complete fix. It seems to me that it would be better to resolve the expat symbols at builf time, but I don't know how to arrange for that. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-01 23:09 Message: Logged In: YES user_id=28380 By the way, this is not an SGI-specific bug. This will bite any Unix system with a modern sysv-style dynamic linker. The priority of this bug should be higher, IMO. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-01 00:53 Message: Logged In: YES user_id=28380 I've been bitten by the same bug. In my case, the problem was with Qt, not GTK. It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything. Here's the patch I use for this problem: --- python/Modules/pyexpat.c 2005-01-06 16:26:13 -08:00 +++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00 @@ -1936,9 +1936,12 @@ } #endif -#define MYCONST(name) - PyModule_AddStringConstant(errors_module, #name, - (char*)XML_ErrorString(name)) +#define MYCONST(name) + { + char *_v = (char*)XML_ErrorString(name); + if (_v) + PyModule_AddStringConstant(errors_module, #name, _v); + } MYCONST(XML_ERROR_NO_MEMORY); MYCONST(XML_ERROR_SYNTAX); ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 06:46 Message: Logged In: YES user_id=471223 pyexpat initializes using its internal copy of expat. libexpat.so is still mapped in (after pyexpat has initilized), but gdb finds the python copy of XML_ErrorString and other functions. I suspect that this will be a problem if the system version of expat is newer than Python's. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-13 06:01 Message: Logged In: YES user_id=6656 1) Good sleuthing. 2) Argh! 3) What happens if you import pyexpat before pygtk? ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 02:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 10:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 09:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 09:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Tue Jul 19 18:50:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jul 2005 09:50:32 -0700 Subject: [ python-Bugs-665336 ] win32 os.path.normpath not correct for leading slash cases Message-ID: Bugs item #665336, was opened at 2003-01-09 22:42 Message generated for change (Comment added) made by gergan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470 Please note that this message 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: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: win32 os.path.normpath not correct for leading slash cases Initial Comment: os.path.normpath on win32 misses two cases in its duplicate slash removal code that I believe should be dealt with: c:\x\y\z \\x\y\z Both of these are returned unchanged. I've attached an implementation that fixes these to return the following, respectively: c:\x\y\z \x\y\z I did see the other normpath bugs that were reported and rejected and think that the above isn't also a case of "garbage in garbage out" but of course there's room for interpretation. I am a bit unsure about the UNC case since Posix collapses only 3+ leading slashes to a single slash and otherwise leaves up to two slashes. But in the context of win32 the above seems to make more sense to me. Thanks, Stephan Deibel Wing IDE Developer Archaeopteryx Software -------------------- def normpath(path): """Normalize path, eliminating double slashes, etc.""" path = path.replace("/", "\") prefix, path = os.path.splitdrive(path) if prefix == '': max_leading = 2 else: max_leading = 1 i = 0 while path[:1] == "\": if i < max_leading: prefix = prefix + "\" i += 1 path = path[1:] comps = path.split("\") i = 0 while i < len(comps): if comps[i] in ('.', ''): del comps[i] elif comps[i] == '..': if i > 0 and comps[i-1] != '..': del comps[i-1:i+1] i -= 1 elif i == 0 and prefix.endswith("\"): del comps[i] else: i += 1 else: i += 1 # If the path is now empty, substitute '.' if not prefix and not comps: comps.append('.') return prefix + "\".join(comps) ---------------------------------------------------------------------- Comment By: gergan (gergan) Date: 2005-07-19 18:50 Message: Logged In: YES user_id=1301159 I'm experiencing the same bug on linux with Python 2.4.1 (#1, Jun 28 2005, 21:03:32) [GCC 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)] all the paths beginning with double slash are left unchanged from os.path.normpath. so expected behaviour would be (as stated in the documentation) >>>os.path.normpath ("//usr/lib") '/usr/lib' the actual result is: >>>os.path.normpath ("//usr/lib") '//usr/lib' ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-19 21:25 Message: Logged In: YES user_id=752496 I've the following behaviour in 2.4b1: >>> os.path.normpath(r"\x\y\z") '\x\y\z' >>> os.path.normpath(r"\x\y\z") '\x\y\z' >>> os.path.normpath(r"\x\y\z") '\x\y\z' which is ok to me, and >>> os.path.normpath(r"\x\y\z") '\\x\y\z' which seems bad. I'm setting this bug to the 2.4 group. ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2004-11-17 05:04 Message: Logged In: YES user_id=12608 Good god, notification email is munging the number of backslashes inconsistently depending on quoting -- see the sf bug entry in a browser to see the right thing. Sorry about that! ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2004-11-17 05:00 Message: Logged In: YES user_id=12608 The c:\x\y\z case was broken up to 2.3.4 but appears fixed in 2.4b2, as you noticed (it used to return "c:\\x\y\z" and now returns "c:\x\y\z" as it should). However in 2.4b4 the \x\y\z case still returns "\\x\y\z" (it returns any number of leading backslashes unchanged, no matter how many are passed in): >>> os.path.normpath(r"\x\y\z") '\\x\y\z' >>> os.path.normpath(r"\\x\y\z") '\\\x\y\z' I'm still fairly sure it should return "\x\y\z" instead as the more appropriate normalization of this kind of path on win32. Hope that helps! Thanks for your work on clearing the bug list! ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-17 00:17 Message: Logged In: YES user_id=752496 Don't understand what you're proposing: in Py2.4b2 (Win2K SP4) I got: >>> os.path.normpath("c:\x\y\z") 'c:\x\y\z' and that seems ok to me. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-17 00:17 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470 From noreply at sourceforge.net Tue Jul 19 18:59:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jul 2005 09:59:37 -0700 Subject: [ python-Bugs-665336 ] win32 os.path.normpath not correct for leading slash cases Message-ID: Bugs item #665336, was opened at 2003-01-09 22:42 Message generated for change (Comment added) made by gergan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470 Please note that this message 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: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: win32 os.path.normpath not correct for leading slash cases Initial Comment: os.path.normpath on win32 misses two cases in its duplicate slash removal code that I believe should be dealt with: c:\x\y\z \\x\y\z Both of these are returned unchanged. I've attached an implementation that fixes these to return the following, respectively: c:\x\y\z \x\y\z I did see the other normpath bugs that were reported and rejected and think that the above isn't also a case of "garbage in garbage out" but of course there's room for interpretation. I am a bit unsure about the UNC case since Posix collapses only 3+ leading slashes to a single slash and otherwise leaves up to two slashes. But in the context of win32 the above seems to make more sense to me. Thanks, Stephan Deibel Wing IDE Developer Archaeopteryx Software -------------------- def normpath(path): """Normalize path, eliminating double slashes, etc.""" path = path.replace("/", "\") prefix, path = os.path.splitdrive(path) if prefix == '': max_leading = 2 else: max_leading = 1 i = 0 while path[:1] == "\": if i < max_leading: prefix = prefix + "\" i += 1 path = path[1:] comps = path.split("\") i = 0 while i < len(comps): if comps[i] in ('.', ''): del comps[i] elif comps[i] == '..': if i > 0 and comps[i-1] != '..': del comps[i-1:i+1] i -= 1 elif i == 0 and prefix.endswith("\"): del comps[i] else: i += 1 else: i += 1 # If the path is now empty, substitute '.' if not prefix and not comps: comps.append('.') return prefix + "\".join(comps) ---------------------------------------------------------------------- Comment By: gergan (gergan) Date: 2005-07-19 18:59 Message: Logged In: YES user_id=1301159 nevermind, it actually is not a bug as the comment says it all # POSIX allows one or two initial slashes, but treats three or more # as single slash. I didn't know this. Excuse me and forget my posting ::)) ---------------------------------------------------------------------- Comment By: gergan (gergan) Date: 2005-07-19 18:50 Message: Logged In: YES user_id=1301159 I'm experiencing the same bug on linux with Python 2.4.1 (#1, Jun 28 2005, 21:03:32) [GCC 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)] all the paths beginning with double slash are left unchanged from os.path.normpath. so expected behaviour would be (as stated in the documentation) >>>os.path.normpath ("//usr/lib") '/usr/lib' the actual result is: >>>os.path.normpath ("//usr/lib") '//usr/lib' ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-19 21:25 Message: Logged In: YES user_id=752496 I've the following behaviour in 2.4b1: >>> os.path.normpath(r"\x\y\z") '\x\y\z' >>> os.path.normpath(r"\x\y\z") '\x\y\z' >>> os.path.normpath(r"\x\y\z") '\x\y\z' which is ok to me, and >>> os.path.normpath(r"\x\y\z") '\\x\y\z' which seems bad. I'm setting this bug to the 2.4 group. ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2004-11-17 05:04 Message: Logged In: YES user_id=12608 Good god, notification email is munging the number of backslashes inconsistently depending on quoting -- see the sf bug entry in a browser to see the right thing. Sorry about that! ---------------------------------------------------------------------- Comment By: Stephan R.A. Deibel (sdeibel) Date: 2004-11-17 05:00 Message: Logged In: YES user_id=12608 The c:\x\y\z case was broken up to 2.3.4 but appears fixed in 2.4b2, as you noticed (it used to return "c:\\x\y\z" and now returns "c:\x\y\z" as it should). However in 2.4b4 the \x\y\z case still returns "\\x\y\z" (it returns any number of leading backslashes unchanged, no matter how many are passed in): >>> os.path.normpath(r"\x\y\z") '\\x\y\z' >>> os.path.normpath(r"\\x\y\z") '\\\x\y\z' I'm still fairly sure it should return "\x\y\z" instead as the more appropriate normalization of this kind of path on win32. Hope that helps! Thanks for your work on clearing the bug list! ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-17 00:17 Message: Logged In: YES user_id=752496 Don't understand what you're proposing: in Py2.4b2 (Win2K SP4) I got: >>> os.path.normpath("c:\x\y\z") 'c:\x\y\z' and that seems ok to me. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-17 00:17 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470 From noreply at sourceforge.net Tue Jul 19 19:21:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jul 2005 10:21:46 -0700 Subject: [ python-Bugs-1241006 ] Distutils does not use logging Message-ID: Bugs item #1241006, was opened at 2005-07-19 17:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470 Please note that this 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: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils does not use logging Initial Comment: distutils.log creates its own PEP 282-like logger class, which is fine from the distutils point of view, but not exactly brilliant if you want to intercept the calls using the logging facilities that have been in python since 2.3. Recommended fix: If, in fact, distutils.log has to be kept compatible with 2.1 as is claimed in the source file then something along the lines of: try: import logging _global_log = logging.getLogger('distutils') except ImportError: #insert current Log class definition here _global_log = Log() Also, changing the values for DEBUG, INFO, WARN, ERROR and FATAL to be the same as the ones in logging.py is probably a good idea. The distutils logger should have its own formatter that prints out lines as the thing currently does, but this formatter should be set within the code for setup() rather than in the log module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470 From noreply at sourceforge.net Wed Jul 20 11:37:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 02:37:18 -0700 Subject: [ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files Message-ID: Bugs item #1200686, was opened at 2005-05-12 16:19 Message generated for change (Comment added) made by julien_sagnard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 Please note that this 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: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError raised on win32 for correct files Initial Comment: Try to import the attached file (dt.py) on Windows with Python 2.4 or 2.4.1 and you'll get a SyntaxError (the file was written a long time ago, and worked perfectly well on Python 2.1, 2.2 and 2.3.) The same does not happen when importing the same module on Linux (tested with 2.4 and 2.4.1). When the module imports fine you'll get an ImportError (don't want to attach all dependencies here) but the SyntaxError comes before that. Also note that compiling the file with compiler.compileFile("dt.py") generates a perfectly good .pyc file that can be later imported just fine (tested with 2.4 and 2.4.1 on Windows). ---------------------------------------------------------------------- Comment By: Julien Sagnard (julien_sagnard) Date: 2005-07-20 11:37 Message: Logged In: YES user_id=1181710 It's ok if I remove coding declaration. I have no access to current cvs, but if someone send me a zip with latest version, I can try it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-07-19 18:19 Message: Logged In: YES user_id=89016 This bug should be fixed in the current CVS version. So, can you retry with current CVS? As a workaround you might also want to remove the PEP 263 coding declaration if you don't have any special character in your file. ---------------------------------------------------------------------- Comment By: Julien Sagnard (julien_sagnard) Date: 2005-07-19 18:05 Message: Logged In: YES user_id=1181710 I have a similar problem with an other file (log.py). On my computer ( Windows 2000 ) this 2 files ( log.py and dt.py ) works with python 2.4 but raise a syntax error on python 2.4.1 : D:\dvt\tmp\bug2_4_1>python -c "import log" Traceback (most recent call last): File "", line 1, in ? File "D:\dvt\tmp\bug2_4_1\log.py", line 356 w = 72 ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-05-18 16:15 Message: Logged In: YES user_id=86307 I'm fairly sure this is caused by the bug described here: www.python.org/sf/1175396 The module imports without syntax error on my Windows system (with a patched codecs.py to work around the above bug). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470 From noreply at sourceforge.net Wed Jul 20 13:47:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 04:47:03 -0700 Subject: [ python-Bugs-1241507 ] StreamReader broken for byte string to byte string codecs Message-ID: Bugs item #1241507, was opened at 2005-07-20 12: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=1241507&group_id=5470 Please note that this message 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: Graham Horler (grahamh) Assigned to: Nobody/Anonymous (nobody) Summary: StreamReader broken for byte string to byte string codecs Initial Comment: print sys.version 2.4.1 (#2, Jul 12 2005, 09:22:25) [GCC 4.0.1 (Debian 4.0.1-1)] Decoding to what (according to the documentation) should be a byte string (using StreamReader) does one of 2 incorrect things, depending on the default encoding: 1) If the byte string has values not in the current default encoding then StreamReader.read() incorrectly triggers an exception. 2) If the byte string can be accomodated by the current default encoding then StreamReader.read() incorrectly returns a unicode object. The documentation says in lib/standard-encodings.html: "The result of the ``decoding'' direction is listed as operand type in the table." "base64_codec ... byte string" (This bug does not exist in python2.2 or 2.3) The attached script demonstrates the 2 related bugs. Many thanks, Graham ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241507&group_id=5470 From noreply at sourceforge.net Wed Jul 20 15:27:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 06:27:27 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 08: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=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Wed Jul 20 16:47:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 07:47:13 -0700 Subject: [ python-Feature Requests-567972 ] Missing 4 socket object properties Message-ID: Feature Requests item #567972, was opened at 2002-06-12 12:56 Message generated for change (Comment added) made by grahamh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470 Please note that this message 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: 7 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L?wis (loewis) Summary: Missing 4 socket object properties Initial Comment: The C socketmodule has a struct PySocketSockObject, with family, type and proto members. These would be terribly helpful to have access to in Python, when implementing some generic socket helper functions. The "blocking" flag could also be made available, but would require some extra coding. (I'm using Python 2.1.3 under Linux 2.4.16, so I cannot extend the socket class itself ((as in py2.2)), and don't want to slow down sockets with a complete wrapper, as I use them heavily.) Thanks, Graham. ---------------------------------------------------------------------- >Comment By: Graham Horler (grahamh) Date: 2005-07-20 15:47 Message: Logged In: YES user_id=543663 The patch applies, compiles, runs OK for me (thanks). However it does not add access to the blocking flag. Under Linux I can go: fcntl.fcntl(fd, fcntl.F_GETFL) & os.O_NDELAY != 0 But this is not portable, and is probably repeating code. Also the 3 added members are not available from an instance of the _socketobject wrapper, you have to go mysock._sock.family. (The _socketobject wrapper in socket.py is a little bizarre IMVHO.) Perhaps they could be added using instances of property(). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 14:49 Message: Logged In: YES user_id=1188172 Attaching a patch which implements the three members of _socket.socket. Please review. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-15 14:21 Message: Logged In: YES user_id=21627 Sounds good. Would you like to produce a patch implementing this feature? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 13:00 Message: Logged In: YES user_id=543663 Oh yes, the repr of a socket object includes the missing info, so to get hold of the family, I go: int(repr(sock).split(' ')[3].split('=')[1][:-1]) Similar for type and protocol, not nice! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470 From noreply at sourceforge.net Wed Jul 20 17:06:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 08:06:25 -0700 Subject: [ python-Bugs-1241619 ] -m does not find dotted modules Message-ID: Bugs item #1241619, was opened at 2005-07-20 15: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=1241619&group_id=5470 Please note that this message 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: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: -m does not find dotted modules Initial Comment: -m does not appear to find modules that are referenced to with dots on windows: D:\Python24\Lib\site-packages>python -m found python: module found not found D:\Python24\Lib\site-packages>echo print 'found!' > found.py D:\Python24\Lib\site-packages>python -m found found! D:\Python24\Lib\site-packages>mkdir directory D:\Python24\Lib\site-packages>move found.py directory D:\Python24\Lib\site-packages>del found.pyc Could Not Find D:\Python24\Lib\site-packages\found.pyc D:\Python24\Lib\site-packages>python -m found python: module found not found D:\Python24\Lib\site-packages>python -m directory.found python: module directory.found not found D:\Python24\Lib\site-packages>python directory\found.py found! D:\Python24\Lib\site-packages> This should use the standard python finding mechanism to cope with dotted packages. Also with package\__init__.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241619&group_id=5470 From noreply at sourceforge.net Wed Jul 20 19:54:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 10:54:26 -0700 Subject: [ python-Feature Requests-1241619 ] -m does not find dotted modules Message-ID: Feature Requests item #1241619, was opened at 2005-07-20 10:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1241619&group_id=5470 Please note that this message 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: Duplicate Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: -m does not find dotted modules Initial Comment: -m does not appear to find modules that are referenced to with dots on windows: D:\Python24\Lib\site-packages>python -m found python: module found not found D:\Python24\Lib\site-packages>echo print 'found!' > found.py D:\Python24\Lib\site-packages>python -m found found! D:\Python24\Lib\site-packages>mkdir directory D:\Python24\Lib\site-packages>move found.py directory D:\Python24\Lib\site-packages>del found.pyc Could Not Find D:\Python24\Lib\site-packages\found.pyc D:\Python24\Lib\site-packages>python -m found python: module found not found D:\Python24\Lib\site-packages>python -m directory.found python: module directory.found not found D:\Python24\Lib\site-packages>python directory\found.py found! D:\Python24\Lib\site-packages> This should use the standard python finding mechanism to cope with dotted packages. Also with package\__init__.py ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-20 12:54 Message: Logged In: YES user_id=80475 The initial implementation of -m was intentionally confined to the simplest case. The issues pertaining to packages are dealt with through the PEP process: http://www.python.org/peps/pep-0338.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1241619&group_id=5470 From noreply at sourceforge.net Wed Jul 20 23:15:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 14:15:33 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 08:27 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- >Comment By: munder12 (munder12) Date: 2005-07-20 16:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Wed Jul 20 23:20:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 14:20:50 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 13:27 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 21:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 21:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Wed Jul 20 23:24:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 14:24:29 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 09:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-20 17:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 17:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 17:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Thu Jul 21 00:53:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 15:53:21 -0700 Subject: [ python-Bugs-1241507 ] StreamReader broken for byte string to byte string codecs Message-ID: Bugs item #1241507, was opened at 2005-07-20 13:47 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241507&group_id=5470 Please note that this message 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: Graham Horler (grahamh) Assigned to: Nobody/Anonymous (nobody) Summary: StreamReader broken for byte string to byte string codecs Initial Comment: print sys.version 2.4.1 (#2, Jul 12 2005, 09:22:25) [GCC 4.0.1 (Debian 4.0.1-1)] Decoding to what (according to the documentation) should be a byte string (using StreamReader) does one of 2 incorrect things, depending on the default encoding: 1) If the byte string has values not in the current default encoding then StreamReader.read() incorrectly triggers an exception. 2) If the byte string can be accomodated by the current default encoding then StreamReader.read() incorrectly returns a unicode object. The documentation says in lib/standard-encodings.html: "The result of the ``decoding'' direction is listed as operand type in the table." "base64_codec ... byte string" (This bug does not exist in python2.2 or 2.3) The attached script demonstrates the 2 related bugs. Many thanks, Graham ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-07-21 00:53 Message: Logged In: YES user_id=89016 Checked in a fix as: Lib/codecs.py 1.46 Lib/test/test_codecs.py 1.24 Lib/codecs.py 1.35.2.8 Lib/test/test_codecs.py 1.15.2.6 Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241507&group_id=5470 From noreply at sourceforge.net Thu Jul 21 02:04:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 17:04:12 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 08:27 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- >Comment By: munder12 (munder12) Date: 2005-07-20 19:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-20 16:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 16:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 16:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Thu Jul 21 02:35:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 17:35:33 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 09:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-20 20:35 Message: Logged In: YES user_id=31435 I'm intimately familiar with the gc code, and I'm sure this assert has never triggered in any core Python release, or in any Zope release, not even in between-releases buggy development states. It means some memory gc is staring at has an insane value, one that can't possibly arise in intended operation. If you get into gdb (whatever debugger you have), it might be useful to know what value gc_refs _does_ have at this point. One possibility is that you're mixing a debug-build Python (which you are using: asserts never trigger in a release-build Python, simply because the assert() macro expands to nothing then) with one or more release-build extension modules. Trying to mix like that can blow up in all sorts of "impossible" ways. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 20:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-20 17:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 17:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 17:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Thu Jul 21 03:11:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jul 2005 18:11:13 -0700 Subject: [ python-Bugs-1112949 ] ioctl has problems on 64 bit machines Message-ID: Bugs item #1112949, was opened at 2005-01-30 22:55 Message generated for change (Comment added) made by lordsutch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112949&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephen Norris (stephennorris) Assigned to: Nobody/Anonymous (nobody) Summary: ioctl has problems on 64 bit machines Initial Comment: fcntly.ioctl takes an int as the second argument. If the value passed is a large 32 bit quantity (0x80046601 for example - EXT2_IOC_GETFLAGS) then I get: Traceback (most recent call last): File "CommSecure-CVS/Operations/checkSpace.py", line 73, in ? main(sys.argv[1:]) File "CommSecure-CVS/Operations/checkSpace.py", line 25, in main os.path.walk(file, doDirectory, total) File "/usr/lib64/python2.3/posixpath.py", line 282, in walk func(arg, top, names) File "CommSecure-CVS/Operations/checkSpace.py", line 61, in doDirectory flags = fcntl.ioctl(fd, EXT3_IOC_GETFLAGS, " ") OverflowError: signed integer is greater than maximum My _guess_ here is that the code is checking against 32 bit quantities rather than 64 bit when converting to the C data type? Platform is Linux, Fedora Core 3 on AMD Opteron. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2005-07-20 20:11 Message: Logged In: YES user_id=6757 The problem seems to be that Python integers are "long int," while the type expected by ioctl(2) is "unsigned long int" (on AMD64, at least). My hackish workaround is to coerce the ioctl number to a signed quantity: op = struct.unpack('i', struct.pack('I', op))[0] Once it gets into the C code, the signed quantity is then coerced back to unsigned long int by the ioctl call (after an intermediate stop as (signed) int). Probably, the correct course of action here is to figure out what type ioctl(2) uses on a particular architecture and adjust the PyArgs_ParseTuple() call and the type of "op" accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112949&group_id=5470 From noreply at sourceforge.net Thu Jul 21 12:38:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 03:38:57 -0700 Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding Message-ID: Bugs item #1163244, was opened at 2005-03-14 22:20 Message generated for change (Comment added) made by sdahlbac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 13:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) ---------------------------------------------------------------------- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 19:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-15 02:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xbffff584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xbffff584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xbffff634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xbffff634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). ---------------------------------------------------------------------- Comment By: Timo Linna (tilinna) Date: 2005-04-09 11:09 Message: Logged In: YES user_id=1074183 Seems that the connection to n*512 blocks is very likely, and it's not just MBCS-related. I managed to reproduce this with a file that contains an ascii-coding declaration, close-to-1024 bytes section, extra crlf and a comment which raises a SyntaxError in Py2.4.1. Could this be linked to the new codec buffering code? See: www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-21 15:34 Message: Logged In: YES user_id=539787 Could be irrelevant but... are the other block sizes close to n*512 (eg 1536 is 3*512) marks? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-21 14:11 Message: Logged In: YES user_id=14198 I believe this is a different bug than the recent "long-lines" errors (see below). I can reproduce this with a file that uses neither long lines, nor any pywin32 extensions (2.4 branch, trunk) A Python source file containing: -- start snippet -- # -*- coding: mbcs -*- <1532 characters of code or comments> x = {} -- end snippet -- Will yield a SyntaxError when attempting to import the module. Running the module as a script does not provoke the error. To reproduce, there must be exactly 1532 characters where specified (see the attached file for a demo). Adding or removing even a single character will prevent the error. It is possible to replace characters with any others, including valid code, and still see the error - however, the number of characters must remain the same .cr/lf pairs can also be replaced with any other 2 characters. There are other "block sizes" that will provoke the error, but this is the only one I have nailed. Apart from the "block" of 1532 characters, the coding line and the blank line before the dict assignment also appear critical. Unlike the other characters in the block, this last cr/lf pair can not be replaced with comments. I can't provoke the error with other encodings (note there are no encoded characters in the sample - it is trivial). To reproduce, save the attached file on Windows and execute: > python -c "import foo2" Traceback (most recent call last): File "", line 1, in ? File "foo2.py", line 24 x = {} ^ SyntaxError: invalid syntax Note that Python 2.3 and earlier all work. Also note that "python foo2.py" also works. The code is clearly valid. Haven't tried to repro on Linux (mbcs isn't available there, and I can't get a test case that doesn't use it) Other pointers/notes: pywin32 bug 1085454 is related to long-lines, by all accounts that underlying error has been fixed - I can't verify this as pywin32 no longer generates insanely long lines. I can confirm Python bugs 1101726/1089395 still crashes Python 2.3+. I believe all (including this) are discrete bugs. [foo2.py is my attachment - ya gotta love sourceforge :)] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 12:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 From noreply at sourceforge.net Thu Jul 21 20:05:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 11:05:46 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 08:27 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- >Comment By: munder12 (munder12) Date: 2005-07-21 13:05 Message: Logged In: YES user_id=1156202 Well, this gets even stranger. I am not running a debug version of python as far as I can tell. I built 2.4.1 in a fresh directory by: ./configure --prefix=/blah make make test make install The gcmodule was echo'd as being built this way: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c I am leaning toward psyco as being the culprit based on your suggestions since it is the only one that has extra C libraries. I'm running the case with Tkinter, pyro, and psyco all not being imported. Thanks again, Mark ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-20 19:35 Message: Logged In: YES user_id=31435 I'm intimately familiar with the gc code, and I'm sure this assert has never triggered in any core Python release, or in any Zope release, not even in between-releases buggy development states. It means some memory gc is staring at has an insane value, one that can't possibly arise in intended operation. If you get into gdb (whatever debugger you have), it might be useful to know what value gc_refs _does_ have at this point. One possibility is that you're mixing a debug-build Python (which you are using: asserts never trigger in a release-build Python, simply because the assert() macro expands to nothing then) with one or more release-build extension modules. Trying to mix like that can blow up in all sorts of "impossible" ways. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 19:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-20 16:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 16:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 16:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Thu Jul 21 20:25:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 11:25:41 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 09:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-21 14:25 Message: Logged In: YES user_id=31435 This part of the command line you showed: -DNDEBUG causes C's assert() macro to "expand to nothing". That's part of the definition of the C language, not a Python convention. So if you compiled Python with -DNDEBUG, and are seeing an assert() trigger, then I can only conclude one of two things: 1. Your C compiler has a very bad bug. or 2. You're not actually using the Python you think you're using. That said, I've seen very strange bugs triggered by psyco too, but not even psyco can cause code to execute that doesn't exist. No code is generated for an assert() when compiling with -DNDEBUG: the C preprocessor throws assert()s away when NDEBUG is #define'd. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-21 14:05 Message: Logged In: YES user_id=1156202 Well, this gets even stranger. I am not running a debug version of python as far as I can tell. I built 2.4.1 in a fresh directory by: ./configure --prefix=/blah make make test make install The gcmodule was echo'd as being built this way: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c I am leaning toward psyco as being the culprit based on your suggestions since it is the only one that has extra C libraries. I'm running the case with Tkinter, pyro, and psyco all not being imported. Thanks again, Mark ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-20 20:35 Message: Logged In: YES user_id=31435 I'm intimately familiar with the gc code, and I'm sure this assert has never triggered in any core Python release, or in any Zope release, not even in between-releases buggy development states. It means some memory gc is staring at has an insane value, one that can't possibly arise in intended operation. If you get into gdb (whatever debugger you have), it might be useful to know what value gc_refs _does_ have at this point. One possibility is that you're mixing a debug-build Python (which you are using: asserts never trigger in a release-build Python, simply because the assert() macro expands to nothing then) with one or more release-build extension modules. Trying to mix like that can blow up in all sorts of "impossible" ways. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 20:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-20 17:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 17:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 17:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Fri Jul 22 00:22:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 15:22:37 -0700 Subject: [ python-Bugs-1242657 ] list(obj) can swallow KeyboardInterrupt Message-ID: Bugs item #1242657, was opened at 2005-07-22 01: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=1242657&group_id=5470 Please note that this message 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: Steve Alexander (stevea_zope) Assigned to: Nobody/Anonymous (nobody) Summary: list(obj) can swallow KeyboardInterrupt Initial Comment: The example below shows that list(f) swallows the KeyboardInterrupt. It swallows any other exception too, such as MemoryError or application-specific ConflictErrors. I think the "get the length of the object" optimisation should catch only AttributeError and TypeError. >>> class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print "len called. raising Keyboard Interrupt." ... raise KeyboardInterrupt ... >>> f = F() >>> list(f) len called. raising Keyboard Interrupt. [23] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 From noreply at sourceforge.net Fri Jul 22 03:50:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 18:50:53 -0700 Subject: [ python-Bugs-1242657 ] list(obj) can swallow KeyboardInterrupt Message-ID: Bugs item #1242657, was opened at 2005-07-21 17:22 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 Please note that this message 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: Steve Alexander (stevea_zope) >Assigned to: Raymond Hettinger (rhettinger) Summary: list(obj) can swallow KeyboardInterrupt Initial Comment: The example below shows that list(f) swallows the KeyboardInterrupt. It swallows any other exception too, such as MemoryError or application-specific ConflictErrors. I think the "get the length of the object" optimisation should catch only AttributeError and TypeError. >>> class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print "len called. raising Keyboard Interrupt." ... raise KeyboardInterrupt ... >>> f = F() >>> list(f) len called. raising Keyboard Interrupt. [23] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 From noreply at sourceforge.net Fri Jul 22 04:03:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 19:03:15 -0700 Subject: [ python-Bugs-1183972 ] dest parameter in optparse Message-ID: Bugs item #1183972, was opened at 2005-04-15 15:39 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 Please note that this message 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: ahmado (ahmado) Assigned to: Greg Ward (gward) Summary: dest parameter in optparse Initial Comment: When using the "callback" action, optparse requires that you STILL specify a "dest" parameter, though it is not required or used by the option parser. In fact, if you do not include the "dest" parameter, your options will still work properly, but optparse will generate an exception when calling the "--help" option. Not specifying a "dest" parameter will result in the following Exception when using the default "--help" or "- h" option: File "c:\Python23\lib\optparse.py", line 229, in format_option_strings metavar = option.metavar or option.dest.upper() AttributeError: 'NoneType' object has no attribute 'upper' by simply adding a bogus bug, the --help / -h option works properly even though the dest isn't actually used. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2005-07-21 22:03 Message: Logged In: YES user_id=14422 I'm pretty sure I fixed this in Optik 1.5 / Python 2.4. Can you 1) verify if the bug is still there in Python 2.4 and 2) if so, supply a small script demonstrating the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 From noreply at sourceforge.net Fri Jul 22 04:08:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jul 2005 19:08:14 -0700 Subject: [ python-Feature Requests-1222235 ] Bad optparse help wrapping with multiple paragraphs Message-ID: Feature Requests item #1222235, was opened at 2005-06-16 18:18 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1222235&group_id=5470 Please note that this message 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: Barry A. Warsaw (bwarsaw) Assigned to: Greg Ward (gward) Summary: Bad optparse help wrapping with multiple paragraphs Initial Comment: If the help text for an option consists of multiple paragraphs, optparse wraps all the paragraphs into one big mess when --help is used. optparse should really split the text by paragraphs and fill each individual paragraph. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2005-07-21 22:08 Message: Logged In: YES user_id=14422 This sounds an awful lot like Optik RFE #1055954 -- see https://sourceforge.net/tracker/?func=detail&atid=421100&aid=1055954&group_id=38019 . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1222235&group_id=5470 From noreply at sourceforge.net Fri Jul 22 09:08:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 00:08:30 -0700 Subject: [ python-Bugs-1171023 ] Thread.join() fails to release Lock on KeyboardInterrupt Message-ID: Bugs item #1171023, was opened at 2005-03-26 06:40 Message generated for change (Comment added) made by marvinalone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Peter Hansen (phansen) Assigned to: Nobody/Anonymous (nobody) Summary: Thread.join() fails to release Lock on KeyboardInterrupt Initial Comment: In threading.Thread.join(), the Condition/Lock object called self.__block is acquired upon entry, and released on exit without an enclosing try/finally to ensure that the release really occurs. If the join() call has no timeout, the wait() call that occurs inside can never be interrupted so there is no problem. If the join() call has a timeout, however, the wait() occurs in a loop which can be interrupted by a Ctrl-C, raising a KeyboardInterrupt which skips the self.__block.release() call and leaves the Lock acquired. This is a problem if the main thread (which is the only one that will see a KeyboardInterrupt) is the one calling join() and only if the other thread on which the join() is being called is a non-daemon thread or, in the case of a daemon thread, if the main thread subsequently attempts to wait for the other thread to terminate (for example, by monitoring isAlive() on the other thread). In any event, the lack of a try/finally means the joined thread will never really finish because any attempt by it to call its __stop() method will block forever. ---------------------------------------------------------------------- Comment By: Dirk Groeneveld (marvinalone) Date: 2005-07-22 00:08 Message: Logged In: YES user_id=146647 I submitted a (tested) patch for this, the id is 1240614, the link is http://www.python.org/sf/1240614. ---------------------------------------------------------------------- Comment By: Peter Hansen (phansen) Date: 2005-03-28 04:40 Message: Logged In: YES user_id=567267 I confirmed with Brett offline that this bug is indeed distinct from #1167930 and should be reopened. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-03-27 16:46 Message: Logged In: YES user_id=357491 That was supposed to be bug #1167930, not this bug itself. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-03-27 11:02 Message: Logged In: YES user_id=357491 Duplicate of bug #1171023. ---------------------------------------------------------------------- Comment By: Peter Hansen (phansen) Date: 2005-03-26 07:19 Message: Logged In: YES user_id=567267 A workaround (tested) is to subclass Thread and ensure that the lock is released. I'm not certain this is completely safe as written, but I'm assuming that you can safely attempt to release a lock that you don't own and the worst that can happen is you'll get an exception (which the workaround code catches and ignores). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470 From noreply at sourceforge.net Fri Jul 22 18:20:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 09:20:26 -0700 Subject: [ python-Bugs-1243192 ] Incorrect documentation of re.UNICODE Message-ID: Bugs item #1243192, was opened at 2005-07-22 18: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=1243192&group_id=5470 Please note that this 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: nhaldimann (nhaldimann) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect documentation of re.UNICODE Initial Comment: The effects of the re.UNICODE flag are incorrectly documented in the library reference. Currently it says (Section 4.2.3): U UNICODE Make \w, \W, \b, and \B dependent on the Unicode character properties database. New in version 2.0. But this flag in fact also affects \d, \D, \s, and \S at least since Python 2.1 (I have checked 2.1.3 on Linux, 2.2.3, 2.3.5 and 2.4 on OS X and the source of _sre.c makes this obvious). Proof: Python 2.4 (#1, Feb 13 2005, 18:29:12) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> not re.match(r"\d", u"\u0966") True >>> re.match(r"\d", u"\u0966", re.UNICODE) <_sre.SRE_Match object at 0x36ee20> >>> not re.match(r"\s", u"\u2001") True >>> re.match(r"\s", u"\u2001", re.UNICODE) <_sre.SRE_Match object at 0x36ee20> \u0966 is some Indian digit, \u2001 is an em space. I propose to change the docs to: U UNICODE Make \w, \W, \b, \B, \d, \D, \s, and \S dependent on the Unicode character properties database. New in version 2.0. Maybe the documentation of \d, \D, \s, and \S in section 2.4.1 of the library reference should also be adapted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243192&group_id=5470 From noreply at sourceforge.net Fri Jul 22 21:19:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 12:19:22 -0700 Subject: [ python-Bugs-1243288 ] Misuse of "it's" Message-ID: Bugs item #1243288, was opened at 2005-07-22 12:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243288&group_id=5470 Please note that this 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: Joanne Bogart (jrbogart) Assigned to: Nobody/Anonymous (nobody) Summary: Misuse of "it's" Initial Comment: In section 2.3.2 of the Python online reference manual (http://docs.python.org/ref/id-classes.html) the text These names are defined by the interpreter and it's implementation should read These names are defined by the interpreter and its implementation. General rule: if you can't replace "it's" by "it is" and preserve meaning, then "it's" is wrong. This is so trivial I hesitate to submit it. On the other hand, it's a shame that such generally excellent documentation should be marred by this kind of thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243288&group_id=5470 From noreply at sourceforge.net Fri Jul 22 21:48:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jul 2005 12:48:37 -0700 Subject: [ python-Bugs-1243288 ] Misuse of "it's" Message-ID: Bugs item #1243288, was opened at 2005-07-22 21:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243288&group_id=5470 Please note that this 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: Joanne Bogart (jrbogart) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Misuse of "it's" Initial Comment: In section 2.3.2 of the Python online reference manual (http://docs.python.org/ref/id-classes.html) the text These names are defined by the interpreter and it's implementation should read These names are defined by the interpreter and its implementation. General rule: if you can't replace "it's" by "it is" and preserve meaning, then "it's" is wrong. This is so trivial I hesitate to submit it. On the other hand, it's a shame that such generally excellent documentation should be marred by this kind of thing. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-22 21:48 Message: Logged In: YES user_id=1188172 This was already corrected in CVS HEAD. Committed to r24-maint as ref2.tex r1.56.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243288&group_id=5470 From noreply at sourceforge.net Sat Jul 23 14:33:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Jul 2005 05:33:27 -0700 Subject: [ python-Bugs-1243553 ] pydoc on cgi.escape lacks info that are in www docs Message-ID: Bugs item #1243553, was opened at 2005-07-23 15: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=1243553&group_id=5470 Please note that this 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: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc on cgi.escape lacks info that are in www docs Initial Comment: WWW: escape( s[, quote]) Convert the characters "&", "<" and ">" in string s to HTML-safe sequences. Use this if you need to display text that might contain such characters in HTML. If the optional flag quote is true, the double-quote character (""") is also translated; this helps for inclusion in an HTML attribute value, as in . If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead. pydoc cgi.escape = escape(s, quote=None) Replace special characters '&', '<' and '>' by SGML entities. why? ;( moreover pydoc doesn't even say what quote is!! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243553&group_id=5470 From noreply at sourceforge.net Sun Jul 24 14:27:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jul 2005 05:27:09 -0700 Subject: [ python-Bugs-1234985 ] using some_re.sub() often imports sre.__doc__ Message-ID: Bugs item #1234985, was opened at 2005-07-08 23:46 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234985&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Gustavo Niemeyer (niemeyer) Summary: using some_re.sub() often imports sre.__doc__ Initial Comment: Why is __doc__ imported from the builtin sre module when a regular expression is substituted replacing a group? $ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def import_hook(name, globals={}, locals={}, fromlist=[]): ... print name, fromlist ... return original_import(name, globals, locals, fromlist) ... >>> import __builtin__ >>> original_import = __builtin__.__import__ >>> __builtin__.__import__ = import_hook >>> import re re None sre ('*',) sys None sre_compile None _sre None sys None sre_constants ('*',) sre_parse None sys None sre_constants ('*',) sre_parse None copy_reg None sre ('__all__',) >>> re1 = re.compile('foo...bar') sre_parse None >>> re1.sub('x', 'y') 'y' >>> re1.sub('x', 'fooXXXbar') 'x' >>> re2 = re.compile('foo(...)bar') sre_parse None >>> re2.sub('x', 'y') 'y' >>> re2.sub('\1', 'fooXXXbar') sre ['__doc__'] 'XXX' ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-24 14:27 Message: Logged In: YES user_id=174455 Below is the full source of re.py. Does your problem go away when you use sre directly instead? """Minimal "re" compatibility wrapper. See "sre" for documentation.""" engine = "sre" # Some apps might use this undocumented variable from sre import * from sre import __all__ ---------------------------------------------------------------------- Comment By: Steve Alexander (stevea_zope) Date: 2005-07-08 23:52 Message: Logged In: YES user_id=492001 This is significant for programs that use an expensive import hook, and also use this kind of regex. I'm working around this by making my import hook return early for imports from sre. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234985&group_id=5470 From noreply at sourceforge.net Sun Jul 24 14:55:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jul 2005 05:55:36 -0700 Subject: [ python-Bugs-1243553 ] pydoc on cgi.escape lacks info that are in www docs Message-ID: Bugs item #1243553, was opened at 2005-07-23 14:33 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243553&group_id=5470 Please note that this 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: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc on cgi.escape lacks info that are in www docs Initial Comment: WWW: escape( s[, quote]) Convert the characters "&", "<" and ">" in string s to HTML-safe sequences. Use this if you need to display text that might contain such characters in HTML. If the optional flag quote is true, the double-quote character (""") is also translated; this helps for inclusion in an HTML attribute value, as in . If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead. pydoc cgi.escape = escape(s, quote=None) Replace special characters '&', '<' and '>' by SGML entities. why? ;( moreover pydoc doesn't even say what quote is!! ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-24 14:55 Message: Logged In: YES user_id=174455 The documentation from pydoc is generated from doc-strings in the python source. Not only does this limit what you can do with it (hence the need for more elaborate documentation), it is also reasonable that this documentation remains terse. You should consider it more as a quick reference in stead of full-on documentation. I have submitted a small patch (1243910) to include a comment in the doc-string about quote. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243553&group_id=5470 From noreply at sourceforge.net Sun Jul 24 15:20:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jul 2005 06:20:11 -0700 Subject: [ python-Bugs-1243553 ] pydoc on cgi.escape lacks info that are in www docs Message-ID: Bugs item #1243553, was opened at 2005-07-23 15:33 Message generated for change (Comment added) made by nkour You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243553&group_id=5470 Please note that this 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: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc on cgi.escape lacks info that are in www docs Initial Comment: WWW: escape( s[, quote]) Convert the characters "&", "<" and ">" in string s to HTML-safe sequences. Use this if you need to display text that might contain such characters in HTML. If the optional flag quote is true, the double-quote character (""") is also translated; this helps for inclusion in an HTML attribute value, as in . If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead. pydoc cgi.escape = escape(s, quote=None) Replace special characters '&', '<' and '>' by SGML entities. why? ;( moreover pydoc doesn't even say what quote is!! ---------------------------------------------------------------------- >Comment By: Nikos Kouremenos (nkour) Date: 2005-07-24 16:20 Message: Logged In: YES user_id=865368 pterk, thank you ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-07-24 15:55 Message: Logged In: YES user_id=174455 The documentation from pydoc is generated from doc-strings in the python source. Not only does this limit what you can do with it (hence the need for more elaborate documentation), it is also reasonable that this documentation remains terse. You should consider it more as a quick reference in stead of full-on documentation. I have submitted a small patch (1243910) to include a comment in the doc-string about quote. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243553&group_id=5470 From noreply at sourceforge.net Sun Jul 24 17:19:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jul 2005 08:19:30 -0700 Subject: [ python-Bugs-1243945 ] Python function/method/constant names as HTML-tag IDs Message-ID: Bugs item #1243945, was opened at 2005-07-24 11:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243945&group_id=5470 Please note that this 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: Chad Miller (chadmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Python function/method/constant names as HTML-tag IDs Initial Comment: It would be very nice if HTML tag IDs were predictable, and not generated. For instance, when newbie-Joe complains on IRC about his program, I'd much rather be able to point him to http://python.org/doc/current/lib/built-in-funcs#input instead of http://python.org/doc/current/lib/built-in-funcs#l2h-38 or telling him to find it manually. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243945&group_id=5470 From noreply at sourceforge.net Mon Jul 25 14:55:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jul 2005 05:55:53 -0700 Subject: [ python-Bugs-1241545 ] garbage collection asserts failing Message-ID: Bugs item #1241545, was opened at 2005-07-20 08:27 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this 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: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 ---------------------------------------------------------------------- >Comment By: munder12 (munder12) Date: 2005-07-25 07:55 Message: Logged In: YES user_id=1156202 Well, I have what appears to be a working solution: Use python 2.5a0 from CVS. This version works with psyco. I suspect the bug fix to gcmodules.c that added the missing INCREF is the culprit (the one labelled as a backport candidate). As for why the assert was triggering, I have my thoughts. First, gdb when trying to read the core files was confirming the absolute path to the (non-debug) executable I thought I was running but also would not give a valid traceback due to stack corruption. Is it possible that the memory corruption was making it where (__ASSERT_VOID_CAST (0)) was unable to succeed? (This is what assert(expr) is macro'd to when defining NDEBUG.) Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-21 13:25 Message: Logged In: YES user_id=31435 This part of the command line you showed: -DNDEBUG causes C's assert() macro to "expand to nothing". That's part of the definition of the C language, not a Python convention. So if you compiled Python with -DNDEBUG, and are seeing an assert() trigger, then I can only conclude one of two things: 1. Your C compiler has a very bad bug. or 2. You're not actually using the Python you think you're using. That said, I've seen very strange bugs triggered by psyco too, but not even psyco can cause code to execute that doesn't exist. No code is generated for an assert() when compiling with -DNDEBUG: the C preprocessor throws assert()s away when NDEBUG is #define'd. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-21 13:05 Message: Logged In: YES user_id=1156202 Well, this gets even stranger. I am not running a debug version of python as far as I can tell. I built 2.4.1 in a fresh directory by: ./configure --prefix=/blah make make test make install The gcmodule was echo'd as being built this way: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c I am leaning toward psyco as being the culprit based on your suggestions since it is the only one that has extra C libraries. I'm running the case with Tkinter, pyro, and psyco all not being imported. Thanks again, Mark ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-20 19:35 Message: Logged In: YES user_id=31435 I'm intimately familiar with the gc code, and I'm sure this assert has never triggered in any core Python release, or in any Zope release, not even in between-releases buggy development states. It means some memory gc is staring at has an insane value, one that can't possibly arise in intended operation. If you get into gdb (whatever debugger you have), it might be useful to know what value gc_refs _does_ have at this point. One possibility is that you're mixing a debug-build Python (which you are using: asserts never trigger in a release-build Python, simply because the assert() macro expands to nothing then) with one or more release-build extension modules. Trying to mix like that can blow up in all sorts of "impossible" ways. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 19:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-07-20 16:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 16:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2005-07-20 16:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 From noreply at sourceforge.net Mon Jul 25 18:31:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jul 2005 09:31:35 -0700 Subject: [ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7 Message-ID: Bugs item #1244610, was opened at 2005-07-25 09:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 Please note that this 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: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 From noreply at sourceforge.net Mon Jul 25 20:09:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jul 2005 11:09:50 -0700 Subject: [ python-Bugs-1244683 ] logging module needs to that it changed in 2.4 Message-ID: Bugs item #1244683, was opened at 2005-07-25 13: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=1244683&group_id=5470 Please note that this 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: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: logging module needs to that it changed in 2.4 Initial Comment: http://docs.python.org/lib/module-logging.html lacks the standard note "changed in version 2.4". This affects the basic example at http://docs.python.org/lib/minimal-example.html because in 2.3 (including 2.3.5) basicConfig did not accept the example's keyword arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244683&group_id=5470 From noreply at sourceforge.net Mon Jul 25 20:10:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jul 2005 11:10:45 -0700 Subject: [ python-Bugs-1244683 ] logging module doc needs to note that it changed in 2.4 Message-ID: Bugs item #1244683, was opened at 2005-07-25 13:09 Message generated for change (Settings changed) made by aisaac0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244683&group_id=5470 Please note that this 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: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) >Summary: logging module doc needs to note that it changed in 2.4 Initial Comment: http://docs.python.org/lib/module-logging.html lacks the standard note "changed in version 2.4". This affects the basic example at http://docs.python.org/lib/minimal-example.html because in 2.3 (including 2.3.5) basicConfig did not accept the example's keyword arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244683&group_id=5470 From noreply at sourceforge.net Tue Jul 26 01:53:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jul 2005 16:53:07 -0700 Subject: [ python-Bugs-1244864 ] Segfault in Python interpreter 2.3.5 Message-ID: Bugs item #1244864, was opened at 2005-07-25 23: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=1244864&group_id=5470 Please note that this 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: Evil Mr Henry (evilmrhenry) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault in Python interpreter 2.3.5 Initial Comment: Linux, Debian Testing, with Bash shell. If I type "python" at the bash prompt to start the interpreter, then hit the up arrow key (the previous command key), Python segfaults. This only occurs if there are no previous commands in the queue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244864&group_id=5470 From noreply at sourceforge.net Tue Jul 26 15:04:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jul 2005 06:04:54 -0700 Subject: [ python-Bugs-1245224 ] Time module is missing inverse of gmtime() Message-ID: Bugs item #1245224, was opened at 2005-07-26 09: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=1245224&group_id=5470 Please note that this message 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: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Time module is missing inverse of gmtime() Initial Comment: The time module has the inverse function of localtime() in its mktime () function, but is missing the inverse of gmtime(). After a bit of searching, I found the calendar module function timegm (), which claims to be the inverse of gmtime(). Is there any reason the time module shouldn't provide the inverse of gmtime()? It's obviously needed, as the calendar module has a version for its own use since the time module doesn't provide one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245224&group_id=5470 From noreply at sourceforge.net Tue Jul 26 18:38:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jul 2005 09:38:05 -0700 Subject: [ python-Bugs-1245381 ] log() on a big number fails on powerpc64 Message-ID: Bugs item #1245381, was opened at 2005-07-26 18: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=1245381&group_id=5470 Please note that this message 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: Jiri Dluhos (jdluhos) Assigned to: Nobody/Anonymous (nobody) Summary: log() on a big number fails on powerpc64 Initial Comment: The log() function seems to give incorrect results for large numbers on a 64-bit powerpc architecture. The test_math program from the Python test suite fails with the following message: math module, testing with eps 1e-05 constants acos asin atan atan2 ceil cos cosh degrees exp fabs floor fmod frexp hypot ldexp log Traceback (most recent call last): File "test_math.py", line 117, in ? testit('log(10**40, 10)', math.log(10**40, 10), 40) File "test_math.py", line 13, in testit raise TestFailed, '%s returned %f, expected %f'%test.test_support.TestFailed: log(10**40, 10) returned 21.938200, expected 40.000000 Tested on a SMP IBM PowerPC machine, with Python 2.3.4 (64-bit build). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470 From noreply at sourceforge.net Wed Jul 27 16:02:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 07:02:01 -0700 Subject: [ python-Feature Requests-487738 ] weaklist Message-ID: Feature Requests item #487738, was opened at 2001-11-30 20:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487738&group_id=5470 Please note that this 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: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-27 09:02 Message: Logged In: YES user_id=80475 Weaksets would not be warranted unless the use cases demonstrated needs for methods unique to sets (intersection, union, etc). Otherwise, weakdictionaries would suffice and we could avoid bloating the module. Also, I'm not sure weaklists are a good idea. First, it is not clear that the subscription use case can be reliably implemented with gc as the primary means of unsubscribing -- traditionally, that is done with an explicit unsubscribe() call issued by the subscriber. Second, weaklists only have a differential advantage when it comes to maintaining insertion order. It is not clear that that feature is really useful. What is clear is that the approach incurs extra costs for maintaing order and O(n) removal time. When order tracking is necessary, there are reasonable implementations using weakkeydictionaries with the entry values being a sequence number indicating creation order. With that data structure, group notification is still simple: for subscriber in sorted(wkd, key=wkd.__getitem__): self.notify(subscriber, message) This approach incurs an O(n log n) sort cost for each group notify but has only an O(1) deletion cost which is an improvement over weaklists. The only way I see around the deletion time issue is to have a weakdoublylinked list which would allow O(1) deletions, appends, and O(n) iteration. None of this came up on the referenced newsgroup posting because there was NO active discussion. IOW, the idea has not shown any demand and has not been through the basic due diligence needed to tease out the best approach. I recommend leaving this as a recipe until we see a battlehardened implementation, a convincing use case, and some user demand. ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-27 06:51 Message: Logged In: YES user_id=890349 I'm not sure if either is more useful than the other, they both seem to have their advantages. It looks like a set would work for the links I mentioned, but I'd personally like to have the ability to connect to a signal/event with priority, thus needing a list. A weak set could possibly be implemented on top of WeakKeyDictionary? Have weak sets already been implemented somewhere? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-07-26 20:19 Message: Logged In: YES user_id=3066 This might be interesting to have. Would this be more useful than, say, a weak set? Ordering may be important for the publish/subscribe use case, at least to ensure predictability. I've not looked at the contributed code, so can't make any comment on that. ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-26 18:16 Message: Logged In: YES user_id=890349 Mind if I bring this back up? This doesn't seem to be in yet. I didn't look at the implementation, but as for motivation... Andres mentioned his original motivation on a list: http://aspn.activestate.com/ASPN/Mail/Message/python-list/929285 I've also seen it duplicated in this recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056 I'd like to see it in for the same reason. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-12-01 20:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487738&group_id=5470 From noreply at sourceforge.net Wed Jul 27 20:00:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 11:00:51 -0700 Subject: [ python-Feature Requests-487738 ] weaklist Message-ID: Feature Requests item #487738, was opened at 2001-11-30 20:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487738&group_id=5470 Please note that this 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: 4 Submitted By: Andres Tuells (atuells) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weaklist Initial Comment: WeakList are list whose entries are referenced weakly. When the object is gc it is deleted from the weaklist (and from its iterators). To be added to weakref.py ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-07-27 14:00 Message: Logged In: YES user_id=31435 FYI, ZODB has a WeakSet implementation, in utils.py here: http://svn.zope.org/ZODB/trunk/src/ZODB/ I wouldn't add this to the core -- it's very specific to ZODB's needs. For example, it actually uses a weak value dictionary, because ZODB can't assume the set elements are usably comparable or hashable. One thing that "should be" addressed in the core is explained in a long comment there: the core weak containers don't supply a sane way to iterate over their weakly referenced containees. You either risk unpredictable "dict changed size during iteration" exceptions, or unboundedly worse gc behavior (read the comment for more detail). The ZODB WeakSet implementation has to break into the weak-value dict implementation to supply a partially sane way to iterate over its elements ("partially" means it's not incremental, and exposes weakrefs to the client; OTOH, it doesn't suffer mystery "dict changed size" exceptions, and plays nicely with gc). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-27 10:02 Message: Logged In: YES user_id=80475 Weaksets would not be warranted unless the use cases demonstrated needs for methods unique to sets (intersection, union, etc). Otherwise, weakdictionaries would suffice and we could avoid bloating the module. Also, I'm not sure weaklists are a good idea. First, it is not clear that the subscription use case can be reliably implemented with gc as the primary means of unsubscribing -- traditionally, that is done with an explicit unsubscribe() call issued by the subscriber. Second, weaklists only have a differential advantage when it comes to maintaining insertion order. It is not clear that that feature is really useful. What is clear is that the approach incurs extra costs for maintaing order and O(n) removal time. When order tracking is necessary, there are reasonable implementations using weakkeydictionaries with the entry values being a sequence number indicating creation order. With that data structure, group notification is still simple: for subscriber in sorted(wkd, key=wkd.__getitem__): self.notify(subscriber, message) This approach incurs an O(n log n) sort cost for each group notify but has only an O(1) deletion cost which is an improvement over weaklists. The only way I see around the deletion time issue is to have a weakdoublylinked list which would allow O(1) deletions, appends, and O(n) iteration. None of this came up on the referenced newsgroup posting because there was NO active discussion. IOW, the idea has not shown any demand and has not been through the basic due diligence needed to tease out the best approach. I recommend leaving this as a recipe until we see a battlehardened implementation, a convincing use case, and some user demand. ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-27 07:51 Message: Logged In: YES user_id=890349 I'm not sure if either is more useful than the other, they both seem to have their advantages. It looks like a set would work for the links I mentioned, but I'd personally like to have the ability to connect to a signal/event with priority, thus needing a list. A weak set could possibly be implemented on top of WeakKeyDictionary? Have weak sets already been implemented somewhere? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-07-26 21:19 Message: Logged In: YES user_id=3066 This might be interesting to have. Would this be more useful than, say, a weak set? Ordering may be important for the publish/subscribe use case, at least to ensure predictability. I've not looked at the contributed code, so can't make any comment on that. ---------------------------------------------------------------------- Comment By: S. Kochen (g-lite) Date: 2005-07-26 19:16 Message: Logged In: YES user_id=890349 Mind if I bring this back up? This doesn't seem to be in yet. I didn't look at the implementation, but as for motivation... Andres mentioned his original motivation on a list: http://aspn.activestate.com/ASPN/Mail/Message/python-list/929285 I've also seen it duplicated in this recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056 I'd like to see it in for the same reason. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:35 Message: Logged In: YES user_id=3066 Oops, I meant to adjust the priority on this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 00:31 Message: Logged In: YES user_id=3066 Needs motivation. Without an need for the data structure, this will be rejected. Lowering priority and marking this for consideration for Python 2.3; it's too late to add this for Python 2.2. Set to "pending" while awaiting an explanation of the motivation. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-12-01 20:07 Message: Logged In: YES user_id=21627 Thanks for the patch. I would recommend to publish it as a separate package first, to get user feedback. I can't see this as a universally-useful data type, so I'm not sure it should be added to the standard library. *If* it is added, a number of corrections must be made to the code: - remove removes elements by equality, not identity. I believe in removeAll, you are looking for identical objects, not merely equal ones. - Why is it the right thing to remove elements from the list if the underlying object dies? doesn't this have undesirable side effects on indexing, e.g. when the list is being iterated over? - In the standard library, I think inheriting from UserList is deprecated, in favour of inheriting from list. - It seems that the class creates many unnecessary copies of lists, e.g. in extend, or setslice. - The references create cycles involving WeakList. Since the WeakList refers to ref objects through data, and the ref objects refer to the list throught the callback, the list itself will become garbage as long as list elements remain alive (although GC will detect those cycles). That should be avoided. - What is the point of the infinite loop in __getitem__? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=487738&group_id=5470 From noreply at sourceforge.net Wed Jul 27 22:25:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 13:25:50 -0700 Subject: [ python-Bugs-1231069 ] ioctl has problem with -ive request codes Message-ID: Bugs item #1231069, was opened at 2005-07-01 17:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 Please note that this 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: Barry Alan Scott (barry-scott) Assigned to: Michael Hudson (mwh) Summary: ioctl has problem with -ive request codes Initial Comment: On Linux many ioctl request code values cannot be passed to ioctl because it assumes that the values are signed ints. Value with the top bit set 0x8000000 are common. Changing the PyArg_ParseTuple calls to use "I" instead of "i" fixes the problem. This may well also be the issue with bug 1112949 "ioctl has problems on 64 bit machines". The attached patch fixes the problem in 2.4.1 and was tested on FC4. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-07-27 21:25 Message: Logged In: YES user_id=6656 Finally committed this as: Modules/fcntlmodule.c revision 2.44 Misc/NEWS revision 1.1326 Thanks, and sorry for the delay... ---------------------------------------------------------------------- Comment By: Barry Alan Scott (barry-scott) Date: 2005-07-18 11:57 Message: Logged In: YES user_id=28665 I've messed up attchments on SF before but the patch downloads for me. Barry ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-03 15:50 Message: Logged In: YES user_id=6656 The patch seems to be empty (!?) Good idea, although not goo enough for me to fight CVS over dialup... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 From noreply at sourceforge.net Wed Jul 27 22:27:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 13:27:07 -0700 Subject: [ python-Bugs-1231069 ] ioctl has problem with -ive request codes Message-ID: Bugs item #1231069, was opened at 2005-07-01 17:24 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Michael Hudson (mwh) Summary: ioctl has problem with -ive request codes Initial Comment: On Linux many ioctl request code values cannot be passed to ioctl because it assumes that the values are signed ints. Value with the top bit set 0x8000000 are common. Changing the PyArg_ParseTuple calls to use "I" instead of "i" fixes the problem. This may well also be the issue with bug 1112949 "ioctl has problems on 64 bit machines". The attached patch fixes the problem in 2.4.1 and was tested on FC4. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-27 21:25 Message: Logged In: YES user_id=6656 Finally committed this as: Modules/fcntlmodule.c revision 2.44 Misc/NEWS revision 1.1326 Thanks, and sorry for the delay... ---------------------------------------------------------------------- Comment By: Barry Alan Scott (barry-scott) Date: 2005-07-18 11:57 Message: Logged In: YES user_id=28665 I've messed up attchments on SF before but the patch downloads for me. Barry ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-07-03 15:50 Message: Logged In: YES user_id=6656 The patch seems to be empty (!?) Good idea, although not goo enough for me to fight CVS over dialup... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 From noreply at sourceforge.net Thu Jul 28 01:07:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 16:07:11 -0700 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 (Tracker Item Submitted) made by Item Submitter 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... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 From noreply at sourceforge.net Thu Jul 28 04:18:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 19:18:29 -0700 Subject: [ python-Bugs-1246473 ] line numbers off by 1 Message-ID: Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 Please note that this 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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 From noreply at sourceforge.net Thu Jul 28 04:19:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 19:19:17 -0700 Subject: [ python-Bugs-1246473 ] line numbers off by 1 for co_firstlineno Message-ID: Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 Please note that this 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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) >Summary: line numbers off by 1 for co_firstlineno Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 From noreply at sourceforge.net Thu Jul 28 04:28:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 19:28:14 -0700 Subject: [ python-Bugs-1246473 ] line numbers off by 1 in dis Message-ID: Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 Please note that this 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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) >Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 From noreply at sourceforge.net Thu Jul 28 04:40:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 19:40:14 -0700 Subject: [ python-Bugs-1246473 ] line numbers off by 1 in dis Message-ID: Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 Please note that this 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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 From noreply at sourceforge.net Thu Jul 28 05:59:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 20:59:49 -0700 Subject: [ python-Bugs-1246473 ] line numbers off by 1 in dis Message-ID: Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 Please note that this 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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-27 20:59 Message: Logged In: YES user_id=357491 I have test_dis now passing thanks to some refactoring to handle the initial line. Now I just need to try to fix test_bug_708901. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 From noreply at sourceforge.net Thu Jul 28 07:25:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 22:25:51 -0700 Subject: [ python-Bugs-1246473 ] line numbers off by 1 in dis Message-ID: Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 Please note that this 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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-27 22:25 Message: Logged In: YES user_id=357491 I don't think this last problem is easily fixed. If you look at the AST, only statements have a lineno attribute. But it is an expression that is on another line from the main line of the statement. I cannot think of any way to get the line information from the statement without adding a lineno attribute to expressions and removing it from statements. That should give the coverage needed to know when another line is being outputted. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 20:59 Message: Logged In: YES user_id=357491 I have test_dis now passing thanks to some refactoring to handle the initial line. Now I just need to try to fix test_bug_708901. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 From noreply at sourceforge.net Thu Jul 28 07:51:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jul 2005 22:51:52 -0700 Subject: [ python-Bugs-1246473 ] line numbers off by 1 in dis Message-ID: Bugs item #1246473, was opened at 2005-07-27 19:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 Please note that this 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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: line numbers off by 1 in dis Initial Comment: test_dis.py:test_dis is failing for two reasons: the line numbers are off by one (need to be bumped up) and the peepholer is not being used and thus the LOAD_CONST(None);RETURN_VALUE idiom is still being tacked on to everything. The former problem needs to be fixed while the latter is not an issue and thus the test needs to get tweaked to allow for the return. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-07-27 22:51 Message: Logged In: YES user_id=357491 Rev. 1.1.2.110 of Python/newcompile.c has the fix for test_dis:test_dis. The more thinking I do about it the more I realize that expression nodes in the AST will need to keep a lineno attribute in order to have lnotab to be set properly. That will not be a fun patch to do. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 22:25 Message: Logged In: YES user_id=357491 I don't think this last problem is easily fixed. If you look at the AST, only statements have a lineno attribute. But it is an expression that is on another line from the main line of the statement. I cannot think of any way to get the line information from the statement without adding a lineno attribute to expressions and removing it from statements. That should give the coverage needed to know when another line is being outputted. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 20:59 Message: Logged In: YES user_id=357491 I have test_dis now passing thanks to some refactoring to handle the initial line. Now I just need to try to fix test_bug_708901. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-27 19:40 Message: Logged In: YES user_id=357491 OK, so first oddity; in both Python 2.5 and the AST branch co_firstlineno, when working on a function at the interpreter prompt, is set to 1. But if you look at co_lnotab, AST has '\x05\x01' while 2.5 has '\x00\x01\x05\x01'. If you tack on another line to the test function, AST has '\x05\x01\x05\x01' while 2.5 has '\x00\x01\x05\x01\x05\x01'. The critical thing is the initial '\x00\x01'. Looks like 2.5 tacks that on or somehow decides it needs to state the initial line at 0 is a byte long. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246473&group_id=5470 From noreply at sourceforge.net Thu Jul 28 09:06:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jul 2005 00:06:52 -0700 Subject: [ python-Bugs-1112949 ] ioctl has problems on 64 bit machines Message-ID: Bugs item #1112949, was opened at 2005-01-31 05:55 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112949&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stephen Norris (stephennorris) Assigned to: Nobody/Anonymous (nobody) Summary: ioctl has problems on 64 bit machines Initial Comment: fcntly.ioctl takes an int as the second argument. If the value passed is a large 32 bit quantity (0x80046601 for example - EXT2_IOC_GETFLAGS) then I get: Traceback (most recent call last): File "CommSecure-CVS/Operations/checkSpace.py", line 73, in ? main(sys.argv[1:]) File "CommSecure-CVS/Operations/checkSpace.py", line 25, in main os.path.walk(file, doDirectory, total) File "/usr/lib64/python2.3/posixpath.py", line 282, in walk func(arg, top, names) File "CommSecure-CVS/Operations/checkSpace.py", line 61, in doDirectory flags = fcntl.ioctl(fd, EXT3_IOC_GETFLAGS, " ") OverflowError: signed integer is greater than maximum My _guess_ here is that the code is checking against 32 bit quantities rather than 64 bit when converting to the C data type? Platform is Linux, Fedora Core 3 on AMD Opteron. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-28 09:06 Message: Logged In: YES user_id=1188172 Should be fixed wrt patch 1231069. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2005-07-21 03:11 Message: Logged In: YES user_id=6757 The problem seems to be that Python integers are "long int," while the type expected by ioctl(2) is "unsigned long int" (on AMD64, at least). My hackish workaround is to coerce the ioctl number to a signed quantity: op = struct.unpack('i', struct.pack('I', op))[0] Once it gets into the C code, the signed quantity is then coerced back to unsigned long int by the ioctl call (after an intermediate stop as (signed) int). Probably, the correct course of action here is to figure out what type ioctl(2) uses on a particular architecture and adjust the PyArgs_ParseTuple() call and the type of "op" accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112949&group_id=5470 From noreply at sourceforge.net Thu Jul 28 18:14:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jul 2005 09:14:32 -0700 Subject: [ python-Bugs-1246900 ] failure to build RPM on rhel 3 Message-ID: Bugs item #1246900, was opened at 2005-07-28 12: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=1246900&group_id=5470 Please note that this 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: Patrick Wagstrom (pridkett) Assigned to: Nobody/Anonymous (nobody) Summary: failure to build RPM on rhel 3 Initial Comment: This is on RHEL 3 AS (Taroon update 5) on a dual processor x86_64 machine Attempting to build the RPM from Python.org fails with a very non-descript error message: + mv -f idle idle2.4 + echo '#!/usr/bin/env python2.4' + echo 'import os, sys' + echo 'os.execvp("/usr/bin/python2.4", ["/usr/bin/python2.4", "/usr/lib/python2.4/idlelib/idle.py"] + sys.argv[1:])' + echo 'print "Failed to exec Idle"' + echo 'sys.exit(1)' + chmod 755 /var/tmp/python2.4-2.4.1-root/usr/bin/idle2.4 + cp -a Tools /var/tmp/python2.4-2.4.1-root/usr/lib64/python2.4 + rm -f mainpkg.files + find /var/tmp/python2.4-2.4.1-root/usr/lib64/python2.4/lib-dynload -type f + sed 's|^/var/tmp/python2.4-2.4.1-root|/|' + grep -v -e '_tkinter.so$' error: Bad exit status from /var/tmp/rpm-tmp.97009 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.97009 (%install) So, thinking that it might be something related to tkinter and idel, I tried not building those, but it still fails to complete. It appears that the problem is that nothing is getting put in /usr/lib64 and everything is getting put in /usr/lib. Attempts were made at hacking the spec file to pass --libdir=/usr/lib64 --exec-prefix=/usr to configure and still have the problem that it doesn't put anything in /usr/lib64 even though the spec file, and common logic, would expect there to be files in /usr/lib64. I was able to compile Python 2.4 just fine on the machine and install it, but still it did not have anything in /usr/lib64/python2.4, which is where the architecture specific files should be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246900&group_id=5470 From noreply at sourceforge.net Fri Jul 29 07:40:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jul 2005 22:40:22 -0700 Subject: [ python-Bugs-1244864 ] Segfault in Python interpreter 2.3.5 Message-ID: Bugs item #1244864, was opened at 2005-07-25 19:53 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244864&group_id=5470 Please note that this 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: Evil Mr Henry (evilmrhenry) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault in Python interpreter 2.3.5 Initial Comment: Linux, Debian Testing, with Bash shell. If I type "python" at the bash prompt to start the interpreter, then hit the up arrow key (the previous command key), Python segfaults. This only occurs if there are no previous commands in the queue. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-07-29 01:40 Message: Logged In: YES user_id=593130 Does this happen with 2.4.1? There will probably not be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244864&group_id=5470 From noreply at sourceforge.net Fri Jul 29 07:52:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jul 2005 22:52:21 -0700 Subject: [ python-Bugs-1244864 ] Segfault in Python interpreter 2.3.5 Message-ID: Bugs item #1244864, was opened at 2005-07-25 23:53 Message generated for change (Comment added) made by evilmrhenry You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244864&group_id=5470 Please note that this 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: Evil Mr Henry (evilmrhenry) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault in Python interpreter 2.3.5 Initial Comment: Linux, Debian Testing, with Bash shell. If I type "python" at the bash prompt to start the interpreter, then hit the up arrow key (the previous command key), Python segfaults. This only occurs if there are no previous commands in the queue. ---------------------------------------------------------------------- >Comment By: Evil Mr Henry (evilmrhenry) Date: 2005-07-29 05:52 Message: Logged In: YES user_id=1052361 Does not occur with 2.4.1. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-07-29 05:40 Message: Logged In: YES user_id=593130 Does this happen with 2.4.1? There will probably not be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244864&group_id=5470 From noreply at sourceforge.net Fri Jul 29 13:54:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jul 2005 04:54:11 -0700 Subject: [ python-Bugs-1244683 ] logging module doc needs to note that it changed in 2.4 Message-ID: Bugs item #1244683, was opened at 2005-07-25 18:09 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244683&group_id=5470 Please note that this 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: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: logging module doc needs to note that it changed in 2.4 Initial Comment: http://docs.python.org/lib/module-logging.html lacks the standard note "changed in version 2.4". This affects the basic example at http://docs.python.org/lib/minimal-example.html because in 2.3 (including 2.3.5) basicConfig did not accept the example's keyword arguments. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-07-29 11:54 Message: Logged In: YES user_id=308438 Documentation update checked into CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244683&group_id=5470 From noreply at sourceforge.net Fri Jul 29 15:37:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jul 2005 06:37:49 -0700 Subject: [ python-Bugs-1244864 ] Segfault in Python interpreter 2.3.5 Message-ID: Bugs item #1244864, was opened at 2005-07-26 01:53 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244864&group_id=5470 Please note that this 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: Out of Date Priority: 5 Submitted By: Evil Mr Henry (evilmrhenry) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault in Python interpreter 2.3.5 Initial Comment: Linux, Debian Testing, with Bash shell. If I type "python" at the bash prompt to start the interpreter, then hit the up arrow key (the previous command key), Python segfaults. This only occurs if there are no previous commands in the queue. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-29 15:37 Message: Logged In: YES user_id=1188172 Thanks! As 2.3 is not continued, closing as Out of Date. ---------------------------------------------------------------------- Comment By: Evil Mr Henry (evilmrhenry) Date: 2005-07-29 07:52 Message: Logged In: YES user_id=1052361 Does not occur with 2.4.1. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-07-29 07:40 Message: Logged In: YES user_id=593130 Does this happen with 2.4.1? There will probably not be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244864&group_id=5470 From noreply at sourceforge.net Fri Jul 29 19:20:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jul 2005 10:20:47 -0700 Subject: [ python-Bugs-1238210 ] manual.cls contains an invalid pdf-inquiry Message-ID: Bugs item #1238210, was opened at 2005-07-14 09:43 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 Please note that this 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: Michael Schindler (m-schindler) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: manual.cls contains an invalid pdf-inquiry Initial Comment: I tried to compile the documentation for Python 2.4.1 (download today) but it fails with the message: pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. This is caused by the \pdfinfo call in manual.cls on line 72. I am using teTeX 3.0 where the LaTeX format is based on pdftex. Therefore, the inquiry for pdf, done in manual.cls with \@ifundefined{pdfinfo}{}{...} always returns true, for both pdf and dvi output. A better choice woud be using \ifpdf defined in python.sty Thanks, anyway for the great program! Michael Schindler ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-07-29 13:20 Message: Logged In: YES user_id=3066 I've changed howto.cls and manual.cls to use the \ifpdf test defined in python.sty; that avoids adding a dependency on ifpdf.sty. I think this is right for the teTeX 3.0 users, but I don't have a teTeX 3.0 installation, so I'd appreciate it if someone who does would test. Please re-open (or comment) on this issue if there's still a problem. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 13:00 Message: Logged In: YES user_id=1188172 This is the fix from the old bug. --- manual.cls.orig 2005-05-30 10:02:28.000000000 +0200 +++ manual.cls 2005-05-30 11:16:58.000000000 +0200 @@ -6,9 +6,17 @@ \ProvidesClass{manual} [1998/03/03 Document class (Python manual)] +\RequirePackage{ifpdf} +\newcommand*{\@ifpdftexisnotavailable}{% + \ifpdf + \expandafter\@secondoftwo + \else + \expandafter\@firstoftwo + \fi +} + \RequirePackage{pypaper} \RequirePackage{fancybox} - % Change the options here to get a different set of basic options, but only % if you have to. Paper and font size should be adjusted in pypaper.sty. % @@ -64,7 +72,7 @@ \let\footnotesize\small \let\footnoterule\relax \py at doHorizontalRule% - \@ifundefined{pdfinfo}{}{{ + \@ifpdftexisnotavailable{}{{ % This \def is required to deal with multi-line authors; it % changes \ to ', ' (comma-space), making it pass muster for % generating document info in the PDF file. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-14 12:57 Message: Logged In: YES user_id=1188172 Seems to be also in howto.cls. Closed bug #1071094 as duplicate of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238210&group_id=5470 From noreply at sourceforge.net Sat Jul 30 01:37:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jul 2005 16:37:50 -0700 Subject: [ python-Bugs-1247765 ] "new" not marked as deprecated in the docs Message-ID: Bugs item #1247765, was opened at 2005-07-30 01: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=1247765&group_id=5470 Please note that this 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: J?rgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: "new" not marked as deprecated in the docs Initial Comment: While >>> help('new') shows the deprecation of this module starting with 2.3, the docs at http://www.python.org/doc/current/lib/module-new.html don't. Shouldn't they? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1247765&group_id=5470 From noreply at sourceforge.net Sat Jul 30 07:15:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jul 2005 22:15:12 -0700 Subject: [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 09:58 Message generated for change (Comment added) made by danieljoyce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Please note that this 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: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane at USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane at USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane at USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman at med.ge.com ---------------------------------------------------------------------- Comment By: Daniel Joyce (danieljoyce) Date: 2005-07-29 22:15 Message: Logged In: YES user_id=1321088 I found the problem! :D Around line 394 of PyShell.py roughly, this function: def start_subprocess(self): # spawning first avoids passing a listening socket to the subprocess self.spawn_subprocess() #time.sleep(20) # test to simulate GUI not accepting connection addr = (LOCALHOST, self.port) # Idle starts listening for connection on localhost for i in range(3): time.sleep(i) try: self.rpcclt = MyRPCClient(addr) break except socket.error, err: pass else: self.display_port_binding_error() return None # Accept the connection from the Python execution server self.rpcclt.listening_sock.settimeout(10) try: self.rpcclt.accept() except socket.timeout, err: self.display_no_subprocess_error() return None self.rpcclt.register("stdin", self.tkconsole) self.rpcclt.register("stdout", self.tkconsole.stdout) self.rpcclt.register("stderr", self.tkconsole.stderr) self.rpcclt.register("flist", self.tkconsole.flist) self.rpcclt.register("linecache", linecache) self.rpcclt.register("interp", self) self.transfer_path() self.poll_subprocess() return self.rpcclt It spawns the subprocess, but never manages to talk to it. The socket.timeout exception is raised. Communication to the subprocess fails in here: try: self.rpcclt = MyRPCClient(addr) break except socket.error, err: pass Then, it tries to register the functions with tkconsole, and TkInter seems to die. I haven't dug down into it yet to see what exactly happens. But, I suspect that rpcclt is null when self.rpcclt.register() is called. So, it's not a Tk error. It's an error with trying to contact the subprocess. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2004-01-21 06:44 Message: Logged In: YES user_id=86216 Sean, thanks for the info. Kurt, ring any bells? ---------------------------------------------------------------------- Comment By: Sean McCardell (smccardell) Date: 2004-01-20 13:23 Message: Logged In: YES user_id=956087 Don't know if this sheds any more light, but on WinXP, Python 2.3.3: when starting IDLE with a file to edit (e.g. 'idle foo.py') the edit window becomes visible first. _And_ it has a visible menu bar. But when the shell window becomes visible, it has no menu bar, and the menu bar _disappears_ from the edit window. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-12-31 09:48 Message: Logged In: YES user_id=86216 Unfortunately, not. The bug report was created right before I was going on vacation last summer. Since I'm still on vacation... :,) Well...actually the assumed high "head banger" factor has facilitated my procrastination. Additionally, since I do not use use IDLE, I'm not very motivated to build a debuggable Python and Cygwin and attach to the hung process with gdb and debug. FWIW, I haven't forgetton. The bug report stares me in the face everytime I read my email. Unfortunately, I haven't taken any action. :,( Are you a developer type? If so, would you be willing to try to debug this problem yourself? ---------------------------------------------------------------------- Comment By: Duane Kaufman (duanekaufman) Date: 2003-12-31 07:37 Message: Logged In: YES user_id=574999 Hi, I was wondering if there has been any motion on this item yet? Thanks, Duane ---------------------------------------------------------------------- Comment By: Duane Kaufman (duanekaufman) Date: 2003-08-14 09:53 Message: Logged In: YES user_id=574999 I am seeing the same behavior, and do _not_ see menus when started with a sub-process. Duane ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 09:47 Message: Logged In: YES user_id=86216 > It sounds like you are getting farther than Duane > Kaufman. I don't think so. AFAICT, we are observing the same behavior. > I wonder if he was seeing the initial message in the > shell window like you are. My WAG is yes. Duane, please confirm. > Do you see the menus? No. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 09:39 Message: Logged In: YES user_id=149084 Oh, big differences: Without the -n switch, which makes IDLE act like the 2.2 version, IDLE starts up an execution server subprocess which then connects to the user's GUI. This subprocess is restarted every time the user does a Run/F5 or a Shell/Restart Shell. There are other major differences. The IDLE in 2.3 is the version developed on the IDLEfork project at Sourceforge. It sounds like you are getting farther than Duane Kaufman. I wonder if he was seeing the initial message in the shell window like you are. Do you see the menus? Well, gotta go :-) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 09:06 Message: Logged In: YES user_id=86216 > what bug are you thinking of? Nothing in particular. However, experience has taught me to consider Cygwin bugs when porting to Cygwin... Anyway, I just found a difference between Python 2.2.3 and 2.3 after starting IDLE. Under 2.2.3: $ ps | fgrep python 3308 1400 3308 3092 0 19695 11:57:56 /home/jt/src/python-2.2.3-2/python Under 2.3: $ ps | fgrep python 2244 1400 2244 2864 0 19695 12:02:57 /usr/bin/python2.3 700 2244 2244 3592 0 19695 12:02:58 /usr/bin/python2.3 Note one python process under 2.2.3 and two under 2.3. This may explain why IDLE works under 2.2.3 and not. Were there major IDLE changes between 2.2.3 and 2.3? If so, what? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 08:21 Message: Logged In: YES user_id=149084 Well, that's peculiar. So the subprocess is starting up ok but the menus aren't posted. Now I'm thinking a TK problem -- what bug are you thinking of? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 07:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 07:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 05:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 15:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Sat Jul 30 17:35:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 08:35:20 -0700 Subject: [ python-Bugs-1188231 ] Rebuilding from source on RH9 fails (_tkinter.so missing) Message-ID: Bugs item #1188231, was opened at 2005-04-23 04:21 Message generated for change (Comment added) made by green-ghost You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470 Please note that this 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: Marty Heyman (mheyman) Assigned to: Nobody/Anonymous (nobody) Summary: Rebuilding from source on RH9 fails (_tkinter.so missing) Initial Comment: On a Red Hat 9 system, I downloaded the python2.4-2.4. 1-1pydotorg.src.rpm and, following the web page ran "rpm --rebuild . ..". It went a long for a good long while with no apparent errors and then said: --- RPM build errors: File not found by glob: /var/tmp/python2.4-2.4. 1-root/usr/lib/python2.4/lib-dynload/_tkinter.so* --- I looked in the directory and there is, in fact, no _tkinter.so file(s) there. -- Marty Heyman ---------------------------------------------------------------------- Comment By: green-ghost (green-ghost) Date: 2005-07-31 01:35 Message: Logged In: YES user_id=1321225 I had a similar problem compiling python from source on a (nominally) redhat8 system. For whatever reason, X11 headers were not installed (probably because it's a server I only use from an ssh console). YMMV Try: apt-get install XFree86-devel or: rpm -i XFree86-devel-.rpm ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-03 07:16 Message: Logged In: YES user_id=21627 Ah, so it seems you are lacking the X11 header files. They should have been installed as a dependency on the Tk headers. So this is either a Redhat bug (for not including a dependency of the -dev packages) or a local misconfiguration of some kind (e.g. forcefully installing Tk headers without all prerequisites present). ---------------------------------------------------------------------- Comment By: Marty Heyman (mheyman) Date: 2005-04-23 04:42 Message: Logged In: YES user_id=421967 APOLOGIES: ADDITIONAL INFO FOLLOWS ---Snip from rebuild output follows In file included from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" --- snip ends many more "parse error lines occurred after this. I doubt they're interesting . A bit later, another group of failures begins --Snip starts In file included from /usr/include/tk.h:1361, from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tkDecls.h:37: parse error before '*' token /usr/include/tkDecls.h:39: parse error before "Tk_3DBorderGC" /usr/include/tkDecls.h:45: parse error before "Drawable" /usr/include/tkDecls.h:50: parse error before "Drawable" /usr/include/tkDecls.h:58: parse error before "XEvent" --Snip ends Again, there are many more similar messages following those and then: --Snip starts /usr/include/tkDecls.h:843: `GC' declared as function returning a function ... [parse errors] /usr/include/tkDecls.h:906: `Font' declared as function returning a function --Snip ends There are many such embedded in that group. Then the messages stop followed by a line that says: "running build_scripts" ... and things proceed as if all was OK for hundreds more lines of output before the failure copied into the original report. I captured the complete log and can upload it if needed on request. I'd need to trim it and it doesn't look all that interesting otherwise but then, what do I know :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470 From noreply at sourceforge.net Sat Jul 30 19:51:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 10:51:32 -0700 Subject: [ python-Bugs-1248036 ] error in popen2() reference Message-ID: Bugs item #1248036, was opened at 2005-07-30 13:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248036&group_id=5470 Please note that this 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: Lorenzo Luengo (lolxp) Assigned to: Nobody/Anonymous (nobody) Summary: error in popen2() reference Initial Comment: http://www.python.org/doc/2.4/lib/module-popen2.html says: popen2( cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects (child_stdout, child_stdin). must say: popen2( cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects (child_stdin, child_stdout). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248036&group_id=5470 From noreply at sourceforge.net Sat Jul 30 20:39:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 11:39:30 -0700 Subject: [ python-Bugs-1248036 ] error in popen2() reference Message-ID: Bugs item #1248036, was opened at 2005-07-30 19:51 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248036&group_id=5470 Please note that this 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: Lorenzo Luengo (lolxp) Assigned to: Nobody/Anonymous (nobody) Summary: error in popen2() reference Initial Comment: http://www.python.org/doc/2.4/lib/module-popen2.html says: popen2( cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects (child_stdout, child_stdin). must say: popen2( cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects (child_stdin, child_stdout). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-30 20:39 Message: Logged In: YES user_id=1188172 The docs are correct. Note that the popen2.popen2 method has a different return value than os.popen2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248036&group_id=5470 From noreply at sourceforge.net Sat Jul 30 23:12:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 14:12:46 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-31 09: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=1248119&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Sat Jul 30 23:29:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 14:29:12 -0700 Subject: [ python-Bugs-1248127 ] set of pdb breakpoint fails Message-ID: Bugs item #1248127, was opened at 2005-07-31 09: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=1248127&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: set of pdb breakpoint fails Initial Comment: I can't set any pdb breakpoint. I try the command, (Pdb) break a:847 Breakpoint 4 at /home/joseph/743/rod/a.py:847 I get the message, "pdbtrack: Traceback cue not found" The breakpoint is never activated. Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470 From noreply at sourceforge.net Sun Jul 31 02:07:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 17:07:46 -0700 Subject: [ python-Bugs-1248127 ] set of pdb breakpoint fails Message-ID: Bugs item #1248127, was opened at 2005-07-30 14:29 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: set of pdb breakpoint fails Initial Comment: I can't set any pdb breakpoint. I try the command, (Pdb) break a:847 Breakpoint 4 at /home/joseph/743/rod/a.py:847 I get the message, "pdbtrack: Traceback cue not found" The breakpoint is never activated. Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:07 Message: Logged In: YES user_id=971153 Could you provide an example (if possible a small one)? There are many reasons why a breakpoint may not be reachable.. Also it seems like you are running pdb under emacs, is it correct? Can you reproduce the problem outside of emacs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470 From noreply at sourceforge.net Sun Jul 31 02:33:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 17:33:28 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-30 14:12 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:33 Message: Logged In: YES user_id=971153 I changed bdb.py to print the kind of event it receives as well as as line numbers and here is a session which illustrates the bug... bagira:~/python/dist/src/bug-next1248119> cat t #../python y=[1,2,3,4] x=[ i+1 for i in y] print x bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t event: call; line 1, file event: line; line 1, file event: call; line 2, file t event: line; line 2, file t > /home/ilya/python/dist/src/bug-next1248119/t(2)?() -> y=[1,2,3,4] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] So it appears that the interpreter generates "line" events for every iteration of the loop.. Would this be a bug in the interpreter (and not in pdb/bdb)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Sun Jul 31 02:59:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 17:59:30 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-30 14:12 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:59 Message: Logged In: YES user_id=971153 A bit more information. I looked into what happens in ceval.c and apparently the current behaviour is intentional.. Looks like this piece of code: else if (frame->f_lasti <= *instr_prev) { /* jumping back in the same line forces a trace event */ result = call_trace(func, obj, frame, PyTrace_LINE, Py_None); } in maybe_call_line_trace() is responsible for the extra "line" events.. Seems like this piece of code was added to fix bug #765624. in ceval.c:2.386 So, should this (1248119) bug be dealt with by skipping extra line events in bdb? Any thoughts? Or am I totally lost? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:33 Message: Logged In: YES user_id=971153 I changed bdb.py to print the kind of event it receives as well as as line numbers and here is a session which illustrates the bug... bagira:~/python/dist/src/bug-next1248119> cat t #../python y=[1,2,3,4] x=[ i+1 for i in y] print x bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t event: call; line 1, file event: line; line 1, file event: call; line 2, file t event: line; line 2, file t > /home/ilya/python/dist/src/bug-next1248119/t(2)?() -> y=[1,2,3,4] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] So it appears that the interpreter generates "line" events for every iteration of the loop.. Would this be a bug in the interpreter (and not in pdb/bdb)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Sun Jul 31 04:53:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 19:53:38 -0700 Subject: [ python-Bugs-1248199 ] shelve .sync operation not documented Message-ID: Bugs item #1248199, was opened at 2005-07-31 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=1248199&group_id=5470 Please note that this 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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: shelve .sync operation not documented Initial Comment: The shelve documentation doesn't describe how to flush updates out to the disc file. Without that, a long-running server could go for months without writing out any updates. A server crash would then lose every update. I asked on clpy whether shelve really had such a severe deficiency. Thanks to Robert Kern for mentioning the .sync() method, which does what is needed. The doc should definitely mention this. Shelve is much less useful without it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248199&group_id=5470 From noreply at sourceforge.net Sun Jul 31 05:20:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 20:20:38 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-30 14:12 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 20:20 Message: Logged In: YES user_id=971153 While this behaviour indeed feels like a bug I'm starting to think that it is not.. Observation1: 'step' should stop at every iteration of a list comprehension Observation2: the only difference between 'step' and 'next' is that 'step' steps into function calls (which is not the case here) So, it seems like 'next' should also stop at every iteration of a list comprehenstion. Ie current behaviour is not a bug... Would supporting a numeric argument for the 'next' command make sense? So that 'next 1' would mean "stop when actual line number increases by at least 1"... ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:59 Message: Logged In: YES user_id=971153 A bit more information. I looked into what happens in ceval.c and apparently the current behaviour is intentional.. Looks like this piece of code: else if (frame->f_lasti <= *instr_prev) { /* jumping back in the same line forces a trace event */ result = call_trace(func, obj, frame, PyTrace_LINE, Py_None); } in maybe_call_line_trace() is responsible for the extra "line" events.. Seems like this piece of code was added to fix bug #765624. in ceval.c:2.386 So, should this (1248119) bug be dealt with by skipping extra line events in bdb? Any thoughts? Or am I totally lost? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:33 Message: Logged In: YES user_id=971153 I changed bdb.py to print the kind of event it receives as well as as line numbers and here is a session which illustrates the bug... bagira:~/python/dist/src/bug-next1248119> cat t #../python y=[1,2,3,4] x=[ i+1 for i in y] print x bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t event: call; line 1, file event: line; line 1, file event: call; line 2, file t event: line; line 2, file t > /home/ilya/python/dist/src/bug-next1248119/t(2)?() -> y=[1,2,3,4] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] So it appears that the interpreter generates "line" events for every iteration of the loop.. Would this be a bug in the interpreter (and not in pdb/bdb)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Sun Jul 31 08:02:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 23:02:48 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-31 09:12 Message generated for change (Comment added) made by pepster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- >Comment By: Joseph Heled (pepster) Date: 2005-07-31 18:02 Message: Logged In: YES user_id=86677 You probably never use pdb in a real program, otherwise you would realize what a serious bummer this is. Giving a 'next N' is nice, but will not be a real solution. Somethims it is not easy to know how many iterations there are. And when they are nested etc. If you are convinced this is the desired and reasonable behaviour for next (a point of view I don't share), at least have a different command to skip to the next line. I am sorry but I have no idea if this is easy or hard. Thanks, Joseph ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 15:20 Message: Logged In: YES user_id=971153 While this behaviour indeed feels like a bug I'm starting to think that it is not.. Observation1: 'step' should stop at every iteration of a list comprehension Observation2: the only difference between 'step' and 'next' is that 'step' steps into function calls (which is not the case here) So, it seems like 'next' should also stop at every iteration of a list comprehenstion. Ie current behaviour is not a bug... Would supporting a numeric argument for the 'next' command make sense? So that 'next 1' would mean "stop when actual line number increases by at least 1"... ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 12:59 Message: Logged In: YES user_id=971153 A bit more information. I looked into what happens in ceval.c and apparently the current behaviour is intentional.. Looks like this piece of code: else if (frame->f_lasti <= *instr_prev) { /* jumping back in the same line forces a trace event */ result = call_trace(func, obj, frame, PyTrace_LINE, Py_None); } in maybe_call_line_trace() is responsible for the extra "line" events.. Seems like this piece of code was added to fix bug #765624. in ceval.c:2.386 So, should this (1248119) bug be dealt with by skipping extra line events in bdb? Any thoughts? Or am I totally lost? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 12:33 Message: Logged In: YES user_id=971153 I changed bdb.py to print the kind of event it receives as well as as line numbers and here is a session which illustrates the bug... bagira:~/python/dist/src/bug-next1248119> cat t #../python y=[1,2,3,4] x=[ i+1 for i in y] print x bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t event: call; line 1, file event: line; line 1, file event: call; line 2, file t event: line; line 2, file t > /home/ilya/python/dist/src/bug-next1248119/t(2)?() -> y=[1,2,3,4] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] So it appears that the interpreter generates "line" events for every iteration of the loop.. Would this be a bug in the interpreter (and not in pdb/bdb)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Sun Jul 31 08:30:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jul 2005 23:30:26 -0700 Subject: [ python-Bugs-1248127 ] set of pdb breakpoint fails Message-ID: Bugs item #1248127, was opened at 2005-07-31 09:29 Message generated for change (Comment added) made by pepster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: set of pdb breakpoint fails Initial Comment: I can't set any pdb breakpoint. I try the command, (Pdb) break a:847 Breakpoint 4 at /home/joseph/743/rod/a.py:847 I get the message, "pdbtrack: Traceback cue not found" The breakpoint is never activated. Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- >Comment By: Joseph Heled (pepster) Date: 2005-07-31 18:30 Message: Logged In: YES user_id=86677 I tried a simple example outside emacs and it worked. Here is how it fails in emacs - visit a python buffer Do C-cC-c (py-execute-buffer) run pdb.run("some code") Try to set a breakpoint - get the "pdbtrack: Traceback cue not found" , and breakpoint never executed. I am not sure if it is supposed to work or not. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 12:07 Message: Logged In: YES user_id=971153 Could you provide an example (if possible a small one)? There are many reasons why a breakpoint may not be reachable.. Also it seems like you are running pdb under emacs, is it correct? Can you reproduce the problem outside of emacs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470 From noreply at sourceforge.net Sun Jul 31 15:21:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Jul 2005 06:21:05 -0700 Subject: [ python-Bugs-1248658 ] dir should accept dirproxies for __dict__ Message-ID: Bugs item #1248658, was opened at 2005-07-31 15:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248658&group_id=5470 Please note that this 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: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: dir should accept dirproxies for __dict__ Initial Comment: PyObject_Dir checks if the __dict__ of an object is a dict, if not it is ignored. It should also accept dictproxies. My usecase is an object that doesn't have a real dict, but looks up attributes in another datastructure. When someone asks for the __dict__ of this object I'm dynamicly building a new dictionary. I'd like the __dict__ property to be a immutable value because changing it won't (and shouldn't) affect the underlying object. However, when I return the result of a call to PyDict_NewProxy the builtin function dir will no longer use the contents of the __dict__ attribute, which is counterproductive because supporting dict is a major usecase for supporting a __dict__ attribute in the first place! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248658&group_id=5470 From noreply at sourceforge.net Sun Jul 31 15:24:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Jul 2005 06:24:18 -0700 Subject: [ python-Bugs-1248658 ] dir should accept dirproxies for __dict__ Message-ID: Bugs item #1248658, was opened at 2005-07-31 15:21 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248658&group_id=5470 Please note that this message 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: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: dir should accept dirproxies for __dict__ Initial Comment: PyObject_Dir checks if the __dict__ of an object is a dict, if not it is ignored. It should also accept dictproxies. My usecase is an object that doesn't have a real dict, but looks up attributes in another datastructure. When someone asks for the __dict__ of this object I'm dynamicly building a new dictionary. I'd like the __dict__ property to be a immutable value because changing it won't (and shouldn't) affect the underlying object. However, when I return the result of a call to PyDict_NewProxy the builtin function dir will no longer use the contents of the __dict__ attribute, which is counterproductive because supporting dict is a major usecase for supporting a __dict__ attribute in the first place! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248658&group_id=5470 From noreply at sourceforge.net Sun Jul 31 15:33:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Jul 2005 06:33:11 -0700 Subject: [ python-Bugs-1123727 ] gensuitemodule.processfile fails Message-ID: Bugs item #1123727, was opened at 2005-02-16 08:17 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 Please note that this 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: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: gensuitemodule.processfile fails Initial Comment: gensuitemodule.processfile fails for an application as trivial as Safari, while the same procedure works OK on version 2.3. On version 2.3: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') [lots of dialogs] On version 2.4, same machine: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 222, in processfile verbose=verbose) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 436, in compileaete creatorsignature, dummy = MacOS.GetCreatorAndType(fname) Error: (-43, 'File not found') I'm pretty conviced the application did not move in the 20 seconds between those two invocations :-) Any suggestions? - Jurjen ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-07-31 15:33 Message: Logged In: YES user_id=580910 Integration with the standard library should not be considered to be the holy grail. Libraries outside of the standard library can be developed on a faster pace than Python itself. I wouldn't mind if the standard libary docs mentioned appscript as a better solution than gensuitemodule :-) ---------------------------------------------------------------------- Comment By: has (hhas) Date: 2005-02-25 18:20 Message: Logged In: YES user_id=996627 > When will appscript be incorporated into the standard libraries? Dunno. It should be finished in the next few months. You'd need to ask Jack what the next entry point into the standard library would be. has ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2005-02-25 12:22 Message: Logged In: YES user_id=446428 Yep, you're right. On both 2.3, and 2.4, I get: >>> import MacOS >>> print MacOS.GetCreatorAndType('/Applications/TextEdit.app') Traceback (most recent call last): File "", line 1, in ? Error: (-43, 'File not found') When will appscript be incorporated into the standard libraries? - Jurjen ---------------------------------------------------------------------- Comment By: has (hhas) Date: 2005-02-24 01:53 Message: Logged In: YES user_id=996627 I think the MacOS extension is broken. The gensuitemodule error you observe on Python 2.4 is probably being masked on Python 2.3 by other bugs that have since been cleaned up. e.g. The following errors OMM (OS10.2.8, Python 2.3.3): print MacOS.GetCreatorAndType('/Applications/TextEdit.app') --> MacOS.Error: (-43, 'File not found') Seems to work on non bundle-based applications, but not bundle-based ones. Maybe you could check this and file a new report on the MacOS extension if you can confirm it. has p.s. Note that gensuitemodule and friends are obsolete. See appscript: http://freespace.virgin.net/hamish.sanderson/appscript.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 From noreply at sourceforge.net Sun Jul 31 22:48:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Jul 2005 13:48:48 -0700 Subject: [ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension Message-ID: Bugs item #1248119, was opened at 2005-07-30 14:12 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 13:48 Message: Logged In: YES user_id=971153 > you would realize what a serious bummer this is. I agree: this is a definite inconvenience. But I don't see how it is different from having to step through any other loop. However, I think there is a way to solve both problems at once..See below > Giving a 'next N' is nice, but will not be a real solution. > Somethims it is not easy to know how many iterations there > are. And when they are nested etc. Actually, I did not mean "next N" to skip N iterations, what I meant to have 'next N' (or at least next 1) to skip next N lines of code. I.e stop only when line>=line_where_next_N_happened+N is reached... So it seems like we are talking about the same thing...Right? There are a couple of corner cases which would have to be handled, (e.g keeping track of the current frame, etc) Also "next N" would allow to easily skip over any loops (not just list comprehensions), which I think would be a useful feature... What do you think? ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-30 23:02 Message: Logged In: YES user_id=86677 You probably never use pdb in a real program, otherwise you would realize what a serious bummer this is. Giving a 'next N' is nice, but will not be a real solution. Somethims it is not easy to know how many iterations there are. And when they are nested etc. If you are convinced this is the desired and reasonable behaviour for next (a point of view I don't share), at least have a different command to skip to the next line. I am sorry but I have no idea if this is easy or hard. Thanks, Joseph ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 20:20 Message: Logged In: YES user_id=971153 While this behaviour indeed feels like a bug I'm starting to think that it is not.. Observation1: 'step' should stop at every iteration of a list comprehension Observation2: the only difference between 'step' and 'next' is that 'step' steps into function calls (which is not the case here) So, it seems like 'next' should also stop at every iteration of a list comprehenstion. Ie current behaviour is not a bug... Would supporting a numeric argument for the 'next' command make sense? So that 'next 1' would mean "stop when actual line number increases by at least 1"... ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:59 Message: Logged In: YES user_id=971153 A bit more information. I looked into what happens in ceval.c and apparently the current behaviour is intentional.. Looks like this piece of code: else if (frame->f_lasti <= *instr_prev) { /* jumping back in the same line forces a trace event */ result = call_trace(func, obj, frame, PyTrace_LINE, Py_None); } in maybe_call_line_trace() is responsible for the extra "line" events.. Seems like this piece of code was added to fix bug #765624. in ceval.c:2.386 So, should this (1248119) bug be dealt with by skipping extra line events in bdb? Any thoughts? Or am I totally lost? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:33 Message: Logged In: YES user_id=971153 I changed bdb.py to print the kind of event it receives as well as as line numbers and here is a session which illustrates the bug... bagira:~/python/dist/src/bug-next1248119> cat t #../python y=[1,2,3,4] x=[ i+1 for i in y] print x bagira:~/python/dist/src/bug-next1248119> ../python -m pdb t event: call; line 1, file event: line; line 1, file event: call; line 2, file t event: line; line 2, file t > /home/ilya/python/dist/src/bug-next1248119/t(2)?() -> y=[1,2,3,4] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) n event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] (Pdb) event: line; line 3, file t > /home/ilya/python/dist/src/bug-next1248119/t(3)?() -> x=[ i+1 for i in y] So it appears that the interpreter generates "line" events for every iteration of the loop.. Would this be a bug in the interpreter (and not in pdb/bdb)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 From noreply at sourceforge.net Sun Jul 31 23:04:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Jul 2005 14:04:53 -0700 Subject: [ python-Bugs-1248997 ] 2.3.5 SRPM fails to build without tkinter installed Message-ID: Bugs item #1248997, was opened at 2005-07-31 17: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=1248997&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Laurie Harper (zodiac) Assigned to: Martin v. L?wis (loewis) Summary: 2.3.5 SRPM fails to build without tkinter installed Initial Comment: If tkinter isn't available, rpmbuild fails due to the presence of unpackages files in usr/lib/python-2.3/lib-tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 From noreply at sourceforge.net Sun Jul 31 22:22:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Jul 2005 13:22:41 -0700 Subject: [ python-Bugs-1248127 ] set of pdb breakpoint fails Message-ID: Bugs item #1248127, was opened at 2005-07-30 14:29 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470 Please note that this message 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: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: set of pdb breakpoint fails Initial Comment: I can't set any pdb breakpoint. I try the command, (Pdb) break a:847 Breakpoint 4 at /home/joseph/743/rod/a.py:847 I get the message, "pdbtrack: Traceback cue not found" The breakpoint is never activated. Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 13:22 Message: Logged In: YES user_id=971153 This does not seem like a bug in python. It might be a bug in emacs' python-mode.. (http://sourceforge.net/projects/python-mode/) However, even that is not clear.. C-cC-c in emacs runs py-execute-buffer which seems to make a copy of the current buffer and run python on that copy...Which would obviosly impact handling of filenames I think the mainstream way to run pdb under Emacs is the pdb-mode. (M-x pdb) My suggestion would be to close this bug. ---------------------------------------------------------------------- Comment By: Joseph Heled (pepster) Date: 2005-07-30 23:30 Message: Logged In: YES user_id=86677 I tried a simple example outside emacs and it worked. Here is how it fails in emacs - visit a python buffer Do C-cC-c (py-execute-buffer) run pdb.run("some code") Try to set a breakpoint - get the "pdbtrack: Traceback cue not found" , and breakpoint never executed. I am not sure if it is supposed to work or not. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 17:07 Message: Logged In: YES user_id=971153 Could you provide an example (if possible a small one)? There are many reasons why a breakpoint may not be reachable.. Also it seems like you are running pdb under emacs, is it correct? Can you reproduce the problem outside of emacs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248127&group_id=5470